> > > On 5/16/14, 8:18 AM, Andrew Sullivan wrote: >> ... >> >> First, if resolvers have expectations about consistency of zones and >> so on, then they're broken. The DNS has only ever been loosely >> coherent. You're simply _not allowed_ to make that assumption from >> any point in the network except inside the authoritative server and, >> maybe for certain kinds of consistency, in the slaves of the same >> zone.
"not allowed" is interesting language, since you're "not allowed" to have a cname and other data at the same node, but a lot of CDN's do it. there is no on-the-wire enforcement of many of the "not allowed"'s in the internet system; rather, there are a lot of hopes and prayers many of which are encoded into RFC documents and writ large they say "if you do this it might not work" or "if you don't this it might constrain future evolution" or "if you do this it might irritate others." anycast recursive DNS was in some sense "not allowed" because authority DNS servers now judge the topology of the end system's browser by the topology of the RDNS, which authority DNS servers are "not allowed" to do. centralized RDNS is "not allowed" because end system apps are written with the assumption that these resources will be within the on-campus RTT range (about a millisecond), and those apps are, you guessed it, "not allowed" to make that design assumption. what the marketplace of ideas called the internet system actually enforces is first-mover action. to my shame, microsoft once had to cripple their AXFR logic to send only one record per header because of a widespread bug in BIND4. i said "BIND4 is not allowed to insist on this" and i fixed it, but until the fix got out to the long tail, microsoft was stuck with a bug they never made. the operative rules of the internet system aren't writ in RFC's but rather in the systems deployed earlier than yours, or in some cases, in the systems deployed more widely than yours. we don't have some kind of super-panel who gets to veto ideas that don't fit into the vision of the system as it is evolving and as it will evolve. what we do have is advice: "if you're going to do this, here is a way that works." in many cases, and DNSSEC is an example, the advice has an additional property: "if you want a system like this, here is how everybody else is doing it." in the past, the DNS advice offered by the IETF has all had both properties -- these things work and we're trying to get everybody to do it the same way because we have a vision of the whole internet having this new feature." today we're saying that second part doesn't matter any more. we're saying "because of the market power of centralized RDNS and trickster-ADNS, many old assumptions are no longer valid, and if you want your part of the internet system to perform in this ad-hoc world as remade by the CDN industry, you will need to pass the end system browser's topology information through the RDNS so that the ADNS can see it." this is at best an engineering compromise, not engineering excellence according to some visionary architecture. i'm all for documenting it, but not because prior end systems are in any way "not allowed" to make the assumptions they're making about DNS coherency, or RDNS latency. we're deliberately saying only "if you want to do this, here is what some people are doing" and deliberately withholding any statement to the effect that (as with DNSSEC for example) "the consensus of the DNS part of the IETF is that everybody ought to do this". if we're going to withhold that second part, we have to do so explicitly, because it has been implicit up until now. >> >> Second, the Internet is actually working today using those kinds of >> CDN tricks. Indeed, some of the most important and most successful >> nodes on the Internet rely very heavily on various DNS tricks, and >> without them wouldn't be operating. that last part is a stretch. the CDN world had alternatives and still has alternatives. things like sending deviant A/AAAA responses to hopefully get the end system to connect to a proxy that's nearby does not always work and there exist alternatives that are just as statistically successful. we're not in a world that demanded what i call "stupid DNS tricks" but rather in a world where "stupid DNS tricks" was a way for the CDN industry to shift its costs onto the rest of the internet system -- and they did -- and now we're paying another installment of those costs, with the subnet option. >> If we are serious about "making >> the Internet better", surely we ought to have an opinion on how to >> offer (as well as can be achieved given other strictures) the >> functionality that is in fact ubiquitous. that's not my job now, but when it was, i had other ideas. happy to discuss at the bar, but they aren't germane to this thread. simply put, the costs have been shifted, it doesn't matter what the cost shifter's motives or alternatives were. this turd is in our front yard now and we're far behind on our cleanup effort. my vision of a better internet has less state, and less combinations and permutations of state, than what's implied by subnet option draft. your vision may differ. neither of our visions is worth a damn at this point, we're not going to "make the internet better", we're going to document the weird things people are doing (subnet option) to work aroudn the weird things other people did (move RDNS to a cloud; make ADNS incoherent). nowhere should we say, and in no way can we expect consensus, that any of this is making the internet better, or that it's good engineering. >> I realise that you already >> conceded the point that this particular extension ought to be >> documented since it has a code point. But it seems to me we ought to >> be more enthusiastic than resigned in this case, even if we have to >> hold our collective nose as well. Either those who understand how the >> DNS works will document what to do, or else people who have no clue >> will make more "improvements". if you're capable of being enthusiastic while holding your nose, more power to you. i am not. furthermore, it doesn't matter. all of us are ready to see this option documented, whether holding our noses or not. let's document it. but let's also be clear that this is something the IETF did not develop and that the IETF makes no recommendation about. unlike DNS itself or DNSSEC, the subnet option does not represent an IETF consensus of a vision for the best engineered system having these features. it's just part of a patchwork quilt designed by market forces. vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
