I don't want to spend a lot of time in this rathole (and this will be my last remark on it), but I want to clarify something about what I was trying to say. I suppose I should have picked better language.
On Fri, May 16, 2014 at 07:50:10AM -0700, Paul Vixie wrote: > > "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. The CNAME example is actually the "not allowed" meaning that I had in mind: it's contradictory to the meaning of the term. You're not allowed to depend on consistency among answers in the DNS because, by definition, the DNS is a distributed, loosely coherent system, and therefore depending on consistency is contrary to the definition of the system. You're not allowed to use a CNAME and other data at the same node, because "CNAME" means "the owner name is really this other name": the prohibition of other data there is a consequence of that and having other data at that owner name is absurd. Both of these cases are examples of why violating such assumptions frequently results in surprising behaviour. (I cannot count the number of people to whom I have explained why sometimes answering with a CNAME at their apex makes mail bounce, for instance). > 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." That's all what I meant by "not allowed" is on the Internet. There are no protocol cops, as you know. Therefore, stuff that is contrary to the definition of the system might work sometimes, depending on what various implementations do. But if you rely on it, you could be hosed. > 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. These are both "not allowed" in the sense of "I'm in charge here, and I scold you." That's not what I meant. These cases are not entailments of the very definition of the system, but instead are at most entailed by other inferences about the way the system is designed. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
