On Wed, Jan 01, 2014 at 10:36:10PM +0100, Christian Grothoff wrote: > > Well, my point is that if you expect everybody to first get an RFC through > to document everything they are doing, expect squatting.
As I suggested at the start of this thread, that's actually a different question, and one the IETF needs to engage broadly. I am not sure what to think. On the one hand, I agree with you that there is the practical fact: people might just do this. On the other hand, the reason people historically felt this was ok was because the root zone was (as zones go) small and stable. That is, if you stepped on a namespace at the top level, you had reasons to suppose you weren't getting in anyone's way and precedent to expect that you wouldn't face many negative effects in the future. In the present régime, however, those assumptions are both false. So this might actually just be an education problem to the rest of the world: "You used to think this was safe. It never was, but it used to work. In future, you should expect it to break." > Nobody working on maintaining the software and/or no user community > would be a strong indicator, and that's something one can find out > by looking / asking people. Which people? We have learned (the hard way) on the Internet that any assumption something will go away is extremely brittle. In practice, once you've started using a namespace, it's there for good (or at least a very long time. Just for instance, A6 records have long since been deprecated, but one continues to see some queries). > It is unclear to me how we even _could_ provide such a stable > document, especially for Namecoin and I2P where I don't even > see academic publications documenting the system on the horizon. That's going to be awkward, then. It's kind of hard to justify the allocation of a TLD by this special procedure if it's for some sort of protocol that might never go anywhere and might not even use that TLD in the long run. > For Tor/GNS, we might be able to point to such references, but > of course then we have the problem that the protocols may still > evolve (there are ongoing discussions about changes to ".onion"), > so the "stable" links might then be outdated, whereas the links > we provided might remain current. That's an excellent way to document software systems but a poor way to document specifications. A specification document needs to say, "This is what $x is for." If the purpose of $x changes, you deprecate the old and publish something new in order that someone else can come along and code against whatever the spec is. Should people coding know about the changes that are happening while they're looking at the "stale" spec? Yes, certainly. But at the very least, if one wants to evaluate interoperability, it becomes necessary to point at something stable. Now, you might argue that this is a case of no interoperability. But that's not quite true: the specification is saying (for instance) that an intermediate resolver SHOULD intercept these names and generate RCODE=3. That's a testable question of interoperation. Could it change? Who knows? We need a stable reference in order to know what the behaviour is supposed to be at a given time. I'm willing to help write stubby I-Ds, if need be, to document these things. They wouldn't need to describe everything about the various systems, I think; just to describe the rules about the names in each case. I'll see if I can work up an example today or tomorrow and send it off-list. > Well, you're running a DNS operation doing this, whereas these > are names that should not escape to DNS and users are supposed > to be aware that using those names gives them additional privacy. > Adding some DNS name as the suffix suggests to users that they're > using the "traditional" Internet, and here it is important to > make it clear that they are not. And as it is not just a few > names, just using the label also is not nice, hence "label.i2p". I think this missed the point. It could just as easily say "label.i2p.invalid", for instance, which would guarantee that the whole thing would already be covered by the .invalid rules. The i2p system would need to look for a name ending in "i2p.invalid", of course, which is very slightly more work. But once you're looking at labels, peeling one off is nothing. Now, I suppose some applications would check for names under .invalid and stop immediately, knowing they're not allowed to be looked up. For that reason, we might want to create a special space in (say) .arpa for this. Call it localdef.arpa. Inside localdef.arpa is a completely locally-defined namespace, and applications would be free to do whatever they wanted there. Then you could have i2p.localdef.arpa. Applications that don't know about localdef.arpa still won't block because .arpa is a perfectly good domain. Applications that do will know to strip off localdef.arpa and do stuff according to their magic label. This is _still_ not using the DNS. It's just living comfortably inside the DNS namespace, which is not what setting up random TLDs does. > Given that the code is GPL, why do you then allude to the fact > that it might make lots of money for someone else? It seems pretty clear that most of the alternative-currency systems tend to attract speculators at the beginning. I note that namecoin attempts to blunt this compared to bitcoin, but new currencies are _always_ the domain of speculators at the beginning. To someone interested in the new-TLD business (and I assure you that neither my employer nor I are), that could look like someone trying to make money without "paying their dues". I don't know how far I buy this argument; I'm just trying to point out the collision here between the IETF allocation procedure and the regular TLD allocation procedure at ICANN. (I freely admit that the problem is caused at least partly by the somewhat dubious "cost recovery" amount of US$185,000. If I were boss of the world, there'd be a lot of things I'd change. You may imagine that ICANN's rules would not make my first pass :-). ) > get the value they (presumably) wanted. However, you're right that > this turns the "recursive DNS resolver" into a "recursive resolver". > I'm not exactly sure why you think this would be so terrible, but > I'm happy to debate this issue (I don't even have a particularly > strong opinion). Unfortunately, many people have had the bright idea of injecting things into "the recursive server" in order to "satisfy user expectations". This causes a number of (widely-documented) problems, and in any case relies on a faulty picture of the real data paths for DNS data. It's true that the model is mostly ok for >90% of all traffic, but the problems show up in the minority. Even a very small minority of problems turns into a major headache for help desks -- usually not the help desk of whever had the bright idea. So, the IETF cannot responsibly suggest yet another class of positive answer be added to these intermediate resolvers. NXDOMAIN seems to be harmless. Everything else seems to cause trouble. > > Quite apart from what happens in the presence of DNSSEC (I think it's > > "fails completely"), I think it is in general bad advice to tell > > people to populate their DNS caches with data from outside the DNS. > > Well, it'd be a "resolver cache", not a "DNS cache" at this point ;-). So what happens when that resolver gets a query from an end system that is doing its own validation? What if the CD bit is set on that query? Now, what if different applications on the same end system have different resolver libraries, and one is asking for DNSSEC and the other isn't? Won't that be kinda confusing? All this would need to be spelled out in detail for an intermediate multimode resolver that might synthesize DNS responses. Yes, these are corner cases. Those furry blobs you see in the corners of the DNS are not dust bunnies. They're monsters, and they bite. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop