Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
At 9:43 AM -0400 2005-07-05, Jay R. Ashworth wrote:
Moreover, most of them are unlikely to be willing to just live with the problem, if no other suitable technical solution can be found. Instead, they'll believe the sales pitch of someone else who says that they can fix the problem, even if that's not technically possible.
Well they might. Well, actually, poorly they might.
But that argument seems to play right *to* the alt-root operators, since the "fix" is to switch your customer resolvers to point to one of them.
I disagree. The problem is that there are too many alternatives.
(Assuming, of course, they stay supersets of ICANN, and don't get at cross-purposes with one another.)
The problem is that they are pretty much guaranteed to get at cross-purposes.
In fact, merging them at your resolvers might be the best solution.
I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant. The alternative roots will always be marginal, at best. The problem is that while they are marginal, they can still create serious problems for the rest of us.
But Steve's approach doesn't seem to *me* to play in that direction. Am I wrong?
I'm not sure I understand which Steve you're talking about. Do you mean Steve Gibbard, in his post dated Sun, 3 Jul 2005 22:20:13 -0700 (PDT)? If so, then each country running their own alternative root won't solve the problem of data leaking through the edges. People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods. The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Tue, Jul 05, 2005 at 08:38:41PM +0200, Brad Knowles wrote:
At 9:43 AM -0400 2005-07-05, Jay R. Ashworth wrote:
Moreover, most of them are unlikely to be willing to just live with the problem, if no other suitable technical solution can be found. Instead, they'll believe the sales pitch of someone else who says that they can fix the problem, even if that's not technically possible.
Well they might. Well, actually, poorly they might.
But that argument seems to play right *to* the alt-root operators, since the "fix" is to switch your customer resolvers to point to one of them.
I disagree. The problem is that there are too many alternatives.
To many alt-roots? Or too many alt-TLD's?
(Assuming, of course, they stay supersets of ICANN, and don't get at cross-purposes with one another.)
The problem is that they are pretty much guaranteed to get at cross-purposes.
Well, there have been alt-root zones available for, what 6 or 7 years now? And how many collisions have there actually been in practice? 2? 3?
In fact, merging them at your resolvers might be the best solution.
I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant.
Well, I meant "at your customer recursive resolver servers", since the topic at hand was "what do IAP's do to support their retail customers", but...
The alternative roots will always be marginal, at best. The problem is that while they are marginal, they can still create serious problems for the rest of us.
In the context which people have been discussing, I don't honestly see how they cause "the rest of us" problems. People with domains *in* those aTLD's, yes. But as I noted somewhere else in this thread, the only people who would have un-mirrored aTLD domains would be precisely those who were evangelising for the concept, and it would be in their best interest to be explaining what was going on...
But Steve's approach doesn't seem to *me* to play in that direction. Am I wrong?
I'm not sure I understand which Steve you're talking about. Do you mean Steve Gibbard, in his post dated Sun, 3 Jul 2005 22:20:13 -0700 (PDT)?
I did mean Mr. Gibbard, yes.
If so, then each country running their own alternative root won't solve the problem of data leaking through the edges.
"Data leaking through the edges"...
People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods.
"Real" is *such* a metaphysical term here, isn't it? :-)
The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root.
Stipulated. But whose problem *is* that? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
At 6:11 PM -0400 2005-07-05, Jay R. Ashworth wrote:
I disagree. The problem is that there are too many alternatives.
To many alt-roots? Or too many alt-TLD's?
Too many of the former is likely to lead to having too many of the latter. Both are bad.
The problem is that they are pretty much guaranteed to get at cross-purposes.
Well, there have been alt-root zones available for, what 6 or 7 years now? And how many collisions have there actually been in practice? 2? 3?
We have not yet hit the knee of the curve.
I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant.
Well, I meant "at your customer recursive resolver servers", since the topic at hand was "what do IAP's do to support their retail customers", but...
I don't trust them to write code that will be used in mission-critical situations or places, regardless of where that is. It's not that they don't have the best intentions -- I'm sure that at least some of them do. It's that they don't have the necessary experience. The people I would trust to have enough of the right experience to make something like this work (if that's possible at all) are the same people who wrote Nominum's ANS and CNS. However, I suspect that they would probably be about the last people in the world who would be interested in trying to make something like this work.
People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods.
"Real" is *such* a metaphysical term here, isn't it? :-)
Heh. Shall we use the term IRS? As in Incumbent Root Servers?
The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root.
Stipulated. But whose problem *is* that?
The users will make it our problem, if we don't get this sorted out soon. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Wed, Jul 06, 2005 at 01:06:15AM +0200, Brad Knowles wrote:
The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root.
Stipulated. But whose problem *is* that?
The users will make it our problem, if we don't get this sorted out soon.
It seems to me that "this" is *already* sorted out, and that all of this discussion has been about whether to invent new problems, rather than about whether to solve existing problems. Alternate root servers exist for one plain simple reason: To give their operators their own little playpen of TLDs they can mess around with without ICANN getting in their faces. People who don't want to own and operate TLDs don't actually give a crap about that reason. These operators have been pushing this idea for 6 or 7 years now. Frankly I'm of the view that if the "benefits" of alternate roots were in any way desirable *to anyone other than those who operate them* we'd probably all be using them by now. But we aren't. And probably never will. If we probably never will then the alternate root operators can either stop flogging their dead horse and shuffle off into the sunset, or they can continue to pollute mailing lists with useless discussions about whether they have a right to exist every time the concept is mentioned from now until eternity, just like they do now. Right now, on July 5th 2005, "The whole alternate-root ${STATE}horse" has absolutely zero operational impact on any network operators. So could y'all please perhaps take it to USEnet where it belongs and let this list get back to normal? Thanks, - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On Wed, Jul 06, 2005 at 08:52:09AM +0930, Mark Newton wrote:
Stipulated. But whose problem *is* that?
The users will make it our problem, if we don't get this sorted out soon.
It seems to me that "this" is *already* sorted out, and that all of this discussion has been about whether to invent new problems, rather than about whether to solve existing problems.
Sorry to hear you feel that way, Mark. I'm not entitled to have on-topicness opinions here, but Brad is, and he hasn't told me to shut up yet. ;-)
Alternate root servers exist for one plain simple reason: To give their operators their own little playpen of TLDs they can mess around with without ICANN getting in their faces. People who don't want to own and operate TLDs don't actually give a crap about that reason.
These operators have been pushing this idea for 6 or 7 years now. Frankly I'm of the view that if the "benefits" of alternate roots were in any way desirable *to anyone other than those who operate them* we'd probably all be using them by now.
But we aren't. And probably never will.
I dunno, The China Proposition seemed fairly believable to *me*...
If we probably never will then the alternate root operators can either stop flogging their dead horse and shuffle off into the sunset, or they can continue to pollute mailing lists with useless discussions about whether they have a right to exist every time the concept is mentioned from now until eternity, just like they do now.
Note that I am *not* an alt-root operator, nor do I have any direct or indirect interest in any of them, except that some of my routers are configured to resolve off of them.
Right now, on July 5th 2005, "The whole alternate-root ${STATE}horse" has absolutely zero operational impact on any network operators. So could y'all please perhaps take it to USEnet where it belongs and let this list get back to normal?
My appraisal is that it has about as much direct percentage impact on North American networks as IPv6 and Multicast. And, as Brad notes, there's a believable case to be made that it *might become* an issue to this audience. All those who disagree or don't object to being caught with their pants down are welcome to kill the thread, which I courteously retitled and unthreaded at the outset. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Wed, Jul 06, 2005 at 01:06:15AM +0200, Brad Knowles wrote:
To many alt-roots? Or too many alt-TLD's?
Too many of the former is likely to lead to having too many of the latter. Both are bad.
I don't know that I agree with either of those assertions, absent collision problems, personally, but this subthread officially makes this a religious argument; comments here off-list.
The problem is that they are pretty much guaranteed to get at cross-purposes.
Well, there have been alt-root zones available for, what 6 or 7 years now? And how many collisions have there actually been in practice? 2? 3?
We have not yet hit the knee of the curve.
Perhaps. I think those people are *much* more concerned about this than I think you think they are.
I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant.
Well, I meant "at your customer recursive resolver servers", since the topic at hand was "what do IAP's do to support their retail customers", but...
I don't trust them to write code that will be used in mission-critical situations or places, regardless of where that is.
Wasn't sure which them you meant here...
It's not that they don't have the best intentions -- I'm sure that at least some of them do. It's that they don't have the necessary experience.
The people I would trust to have enough of the right experience to make something like this work (if that's possible at all) are the same people who wrote Nominum's ANS and CNS. However, I suspect that they would probably be about the last people in the world who would be interested in trying to make something like this work.
And then I figured it out. Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither.
People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods.
"Real" is *such* a metaphysical term here, isn't it? :-)
Heh. Shall we use the term IRS? As in Incumbent Root Servers?
I don't have a problem with that one, the amusing connotations notwithstanding. Incumbent isn't a value judgement, it's merely descriptive.
The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root.
Stipulated. But whose problem *is* that?
The users will make it our problem, if we don't get this sorted out soon.
Yup, it is. And my perception is that the cat is *out* of the bag, and fretting about how bad it would be were the cat to get out of the bag (which is my perception of most people's view of this issue) isn't especially productive; the solution is to figure out how to manage the problem. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
At 7:37 PM -0400 2005-07-05, Jay R. Ashworth wrote:
Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither.
In theory, it should be trivial. In practice, I believe that it is quite non-trivial. I believe that we can look around and pretty easily find at least a few examples that demonstrate how difficult it is to get this right. The history of BIND alone is quite instructive, I believe. The fact that everyone and their brother seems to create authoritative-only servers as their 6th grade science project, but there are still relatively few caching-only servers, is another data point.
And my perception is that the cat is *out* of the bag, and fretting about how bad it would be were the cat to get out of the bag (which is my perception of most people's view of this issue) isn't especially productive; the solution is to figure out how to manage the problem.
I'm not sure, but I think we're at the stage where we might just be able to put the genie back in the bottle, if we act fast and we can get suitable alternative mechanisms in place through the existing official IETF/ICANN process. But if we don't get this fixed soon, I fear that we'll never be able to do that. At that point, we've got our private parts hanging out in the wind, and we're depending on the good nature of people not to come along and whack them with baseball bats, and we're depending on good fortune keeping harsh weather away that might result in lightning strikes. There's not much we can do to stop the alternate roots. They already exist, and at least two are currently in operation. However, I think we can look at what it is that they're offering in terms of i18n and see what we can do to address those issues from inside the system. IMO, i18n is the only potentially legitimate thing that alternate roots are capable of providing, and the only thing we need to worry about resolving within the system. Outside of i18n, I don't give a flying flip what the alternate roots do or what services they claim to offer. And that, I believe, is operationally relevant because the outcome will affect us all. If nothing else, code will have to be adapted to match whatever is specified as a result of the IETF/ICANN political process. And we'll all have to update our servers. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.
On Wed, 6 Jul 2005, Brad Knowles wrote:
There's not much we can do to stop the alternate roots. They already exist, and at least two are currently in operation. However, I think we can look at what it is that they're offering in terms of i18n and see what we can do to address those issues from inside the system.
They aren't offering i18n, they're offering l10n, because their systems only work for a small localized community, not the whole international Internet. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
I have the BIND source, its available to the public. You want to know how hard it is? I'll show you. I will write it. Thats what I do for a living. I accept your challenge. See you in six months. FYI: I don't speak for anyone but myself and ADNS/American Webmasters. ----- Original Message ----- From: "Jay R. Ashworth" <jra@baylink.com> To: "NANOG" <nanog@merit.edu> Sent: Tuesday, July 05, 2005 6:37 PM Subject: Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Wed, Jul 06, 2005 at 01:06:15AM +0200, Brad Knowles wrote:
To many alt-roots? Or too many alt-TLD's?
Too many of the former is likely to lead to having too many of the latter. Both are bad.
I don't know that I agree with either of those assertions, absent collision problems, personally, but this subthread officially makes this a religious argument; comments here off-list.
The problem is that they are pretty much guaranteed to get at cross-purposes.
Well, there have been alt-root zones available for, what 6 or 7 years now? And how many collisions have there actually been in practice? 2? 3?
We have not yet hit the knee of the curve.
Perhaps. I think those people are *much* more concerned about this than I think you think they are.
I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant.
Well, I meant "at your customer recursive resolver servers", since the topic at hand was "what do IAP's do to support their retail customers", but...
I don't trust them to write code that will be used in mission-critical situations or places, regardless of where that is.
Wasn't sure which them you meant here...
It's not that they don't have the best intentions -- I'm sure that at least some of them do. It's that they don't have the necessary experience.
The people I would trust to have enough of the right experience to make something like this work (if that's possible at all) are the same people who wrote Nominum's ANS and CNS. However, I suspect that they would probably be about the last people in the world who would be interested in trying to make something like this work.
And then I figured it out.
Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither.
People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods.
"Real" is *such* a metaphysical term here, isn't it? :-)
Heh. Shall we use the term IRS? As in Incumbent Root Servers?
I don't have a problem with that one, the amusing connotations notwithstanding. Incumbent isn't a value judgement, it's merely descriptive.
The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root.
Stipulated. But whose problem *is* that?
The users will make it our problem, if we don't get this sorted out soon.
Yup, it is.
And my perception is that the cat is *out* of the bag, and fretting about how bad it would be were the cat to get out of the bag (which is my perception of most people's view of this issue) isn't especially productive; the solution is to figure out how to manage the problem.
Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
On Tue, Jul 05, 2005 at 08:29:55PM -0500, John Palmer (NANOG Acct) wrote:
I have the BIND source, its available to the public. You want to know how hard it is? I'll show you. I will write it. Thats what I do for a living.
I accept your challenge. See you in six months.
I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant.
Well, I meant "at your customer recursive resolver servers", since the topic at hand was "what do IAP's do to support their retail customers", but...
I don't trust them to write code that will be used in mission-critical situations or places, regardless of where that is.
whatever those are. there are at least 146 DNS varients out there, the number may be higher. about 50ish or so are BIND versions.
Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither.
in theory - its easy. six months... might work debugged working code - a bit longer me thinks. --bill
The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root.
There was a time when email service was almost universally bundled with Internet access service. Nowadays it is quite common for people to get their email service from a different supplier than their access. There is no reason why DNS resolution could not similarly be unbundled from access. Yes, there would be some latency issues to deal with, but they are not insurmountable. And as I mentioned before, one easy way around all this is for people who want to access content in a specific foreign language to sign up for access with an ISP which provides specific support for that foreign language. If you want to get to sites in China using alternate domain names then you simply buy your DSL line from an ISP who uses the alternate roots. And as a bonus, you will probably also be able to get technical support in Chinese as well. All these people complaining about how this divides the Internet and makes it harder for them to talk to someone in China seem to have missed the fact that there is already a divide caused by different languages. If the Internet is to become a global universal network then, by definition, it must become balkanized. --Michael Dillon
On Wed, 6 Jul 2005 Michael.Dillon@btradianz.com wrote:
There is no reason why DNS resolution could not similarly be unbundled from access. Yes, there would be some latency issues to deal with, but they are not insurmountable.
There are security problems too. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
On Wed, 6 Jul 2005, Michael.Dillon@btradianz.com wrote:
The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root.
There was a time when email service was almost universally bundled with Internet access service. Nowadays it is quite common for people to get their email service from a different supplier than their access. There is no reason why DNS resolution could not similarly be unbundled from access.
1. Security ("man-in-the-middle"). 2. Common interoperability. 3. *Common sense.* [Erm, oh yeah, perhaps I shouldn't feed the troll. After all, this is the same guy who thinks that resurrecting the long dead concept of source routed e-mail is scalable.] You really should read RFC2826 sometime. It's quite short, as RFCs go.
If the Internet is to become a global universal network then, by definition, it must become balkanized.
Fragmenting the namespace with "alternate" TLDs, breaking common interoperability, is hardly a path to "universal." BZZZT, try again. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
1. Security ("man-in-the-middle").
VPNs, SSH tunnels, etc. There are ways to solve this problem.
2. Common interoperability.
We do not currently have common interoperability for a whole range of protocols. The most obvious examples are instant messaging and P2P file transfer but there are many more when you start digging. Often common interoperability is not desired by the end users and they are the ones who determine what succeeds at the end of the day.
3. *Common sense.* [Erm, oh yeah, perhaps I shouldn't feed the troll. After all, this is the same guy who thinks that resurrecting the long dead concept of source routed e-mail is scalable.]
Since when did the NANOG mailing list become your personal venue for flinging personal insults at other list members? For the record, I have never suggested that source-routing is a good idea for email nor have I ever suggested that source-routing is scalable. Some people who read my comments on email architecture jumped to knee-jerk conclusions (the wrong conclusions) that I wanted to resurrect UUCP bang-paths. God knows where they got that idea from.
You really should read RFC2826 sometime. It's quite short, as RFCs go.
I have read it and I appreciate the IAB's comments, but it was written at a time when we didn't have as much experience with rootless networks as we do now. The work of various people in Freenet and other P2P technologies shows that it may indeed be technically feasible to have a DNS that does not have one single monolithic root. Received wisdom is always interesting, but sometimes it is wrong. Remember the IETF mantra? Working code and rough consensus. There are two groups that currently have working code and they are cooperating with each other which means that the work is being done in an atmosphere of "rough consensus". The end result is that they *WILL* *WIN* the debate unless you and other naysayers can point out specific and unresolvable technical issues with their work. The gist of the discussion on this list has been that people don't *LIKE* the alt roots, that they don't *FEEL* good about the idea, that they *FEAR* the possible outcomes. Those are not technical issues. I realize that there are some people on this list that want to enforce the one true religion of Internet and discourage non-believers from joining the club, but I don't agree with that approach. I believe that it is better to let the free flow of ideas continue because the Internet is robust enough to survive and thrive in the face of countless experiments including people announcing huge AS-paths and people running alternate DNS roots. Bring it on! --Michael Dillon
On Wed, 6 Jul 2005 Michael.Dillon@btradianz.com wrote:
1. Security ("man-in-the-middle").
VPNs, SSH tunnels, etc. There are ways to solve this problem.
You would use a VPN or SSH tunnel to do what? That's orthogonal to DNS security issues, and illustrates that you haven't read DNSSEC and/or 2826.
2. Common interoperability.
We do not currently have common interoperability for a whole range of protocols.
So what? DNS is one of the protocols where interoperability is not just desirable, it's MANDATORY. Businesses and individuals expect that when they publish an e-mail or Web site hostname, that it be theirs and only theirs no matter where on the Internet it is accessed. FQDNs are considered fixed points of entry, and alternate roots put that name resolution at risk. (But if you had actually read RFC2826, you would already understand this.) Client side users, conversely, expect that published addresses by businesses or individuals go to the intended party. (But if you had actually read RFC2826, you would already understand this.) Introducing fragmented TLDs or the opportunity to supplant the common TLDs places the DNS infrastructure at risk. This is not just FUD -- DNS hijacking in alternate roots has already happened. (But if you had actually read RFC2826, you would already understand this.)
3. *Common sense.* [Erm, oh yeah, perhaps I shouldn't feed the troll. After all, this is the same guy who thinks that resurrecting the long dead concept of source routed e-mail is scalable.]
Since when did the NANOG mailing list become your personal venue for flinging personal insults at other list members?
Nope, not personal -- it's just good to make sure a troll is properly labeled as such. You know, like how cigarettes have bad-for-your-health warnings.
For the record, I have never suggested that source-routing is a good idea for email nor have I ever suggested that source-routing is scalable.
Okay, then, "forced arbitration" (which is interchangeably equivalent to source routing if the arbitrators handle the mail as it transits). Either way, it's been done and doesn't scale, and you didn't get the point (in the same manner that your stubborn ignorance is preventing you from understanding the basic tenets of DNS), so the troll label fits.
You really should read RFC2826 sometime. It's quite short, as RFCs go.
I have read it
In one eye and out the other, perhaps? I wonder why I have such a hard time believing this, considering that I've more or less rehashed its major points right here.
and I appreciate the IAB's comments, but it was written at a time when we didn't have as much experience with rootless networks as we do now.
The DNS is not a rootless network, so this is a pointless comment. On the flip side, there was quite a bit of experience with alternate DNS roots at the time RFC2826 was created -- AlterNIC, which was run and advocated by people just as blinded by ignorance as you. Oh wait, your name wouldn't *actually* be Jim Fleming, would it? -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
----- Original Message ----- From: "Todd Vierling" <tv@duh.org> To: <Michael.Dillon@btradianz.com> Cc: <nanog@merit.edu> Sent: Saturday, July 09, 2005 10:46 AM Subject: Re: The whole alternate-root ${STATE}horse
So what? DNS is one of the protocols where interoperability is not just desirable, it's MANDATORY.
Businesses and individuals expect that when they publish an e-mail or Web site hostname, that it be theirs and only theirs no matter where on the Internet it is accessed. FQDNs are considered fixed points of entry, and alternate roots put that name resolution at risk. (But if you had actually read RFC2826, you would already understand this.)
Please prove that Inclusive Namespace roots put name resolution at risk. Please show how the current NTIA root is more secure than other roots. Again, please refrain from emotional rhetoric driven by religion. What we need is sound technical arguments.
Client side users, conversely, expect that published addresses by businesses or individuals go to the intended party. (But if you had actually read RFC2826, you would already understand this.)
Introducing fragmented TLDs or the opportunity to supplant the common TLDs places the DNS infrastructure at risk. This is not just FUD -- DNS hijacking in alternate roots has already happened. (But if you had actually read RFC2826, you would already understand this.)
Please post a link or give an example. If you mean .BIZ, I would agree, it was hijacked, but by ICANN, not by any Inclusive Roots. It belonged to AtlanticRoot and ICANN deliberatly created a collision. Collisions cause instability and the biggest one was caused by ICANN.
3. *Common sense.* [Erm, oh yeah, perhaps I shouldn't feed the troll. After all, this is the same guy who thinks that resurrecting the long dead concept of source routed e-mail is scalable.]
Since when did the NANOG mailing list become your personal venue for flinging personal insults at other list members?
Nope, not personal -- it's just good to make sure a troll is properly labeled as such. You know, like how cigarettes have bad-for-your-health warnings.
For the record, I have never suggested that source-routing is a good idea for email nor have I ever suggested that source-routing is scalable.
Okay, then, "forced arbitration" (which is interchangeably equivalent to source routing if the arbitrators handle the mail as it transits).
"Forced arbitration"? - Not an Inclusive concept - but it is an ICANN concept (UDRP/WIPO).
On the flip side, there was quite a bit of experience with alternate DNS roots at the time RFC2826 was created -- AlterNIC, which was run and advocated by people just as blinded by ignorance as you.
Oh wait, your name wouldn't *actually* be Jim Fleming, would it?
Todd, I can only ask, and you can ignore the request, but please try to refrain from posting religious/emotional arguments. Everything you have posted above is unsubstantiated and sounds like an emotional and religious position. It is not helpful to introduce emotion and religion into a technical debate about such an important topic. I ditto Karl's point about this sounding like the telco execs in the early 1970's.
-- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
John Palmer
On Sat, 09 Jul 2005 11:23:26 CDT, "John Palmer (NANOG Acct)" said:
Please prove that Inclusive Namespace roots put name resolution at risk.
You did it yourself, a few paragraphs later...
Please post a link or give an example. If you mean .BIZ, I would agree, it was hijacked, but by ICANN, not by any Inclusive Roots. It belonged to AtlanticRoot and ICANN deliberatly created a collision. Collisions cause instability and the biggest one was caused by ICANN.
So AtlanticRoot created a .BIZ, and (presumably) guaranteed to include everything ICANN had - and then ICANN created a conflicting .BIZ, and resolution of .BIZ named was placed at risk. As you were saying?
I didnt realise it was that time of year again already, it feels like only a couple months since the last annual alternate root debate. Still its nice to see all the old kooks still alive and well and not yet locked up in mental homes. I'd better do my part to feed the trolls i guess... On Sat, 9 Jul 2005, John Palmer (NANOG Acct) wrote:
Please prove that Inclusive Namespace roots put name resolution at risk.
No proof is needed, this is not maths. If there are two roots then a query to each server has the potential to return a different reply. The chance of this happening increases over time plus if an alternate root were to become popular their power to challenge authority if a class were found grows.
Client side users, conversely, expect that published addresses by businesses or individuals go to the intended party.
This is the key point, clients and domain owners need this consistency. Read this a few times and consider how you'd feel if $large_provider decided to point your domain name or their competitors domains to their website .. its the same problem.
Introducing fragmented TLDs or the opportunity to supplant the common TLDs places the DNS infrastructure at risk. This is not just FUD -- DNS hijacking in alternate roots has already happened. (But if you had actually read RFC2826, you would already understand this.)
Please post a link or give an example. If you mean .BIZ, I would agree, it was hijacked, but by ICANN, not by any Inclusive Roots. It belonged to AtlanticRoot and ICANN deliberatly created a collision. Collisions cause instability and the biggest one was caused by ICANN.
Those who consider ICANN the authority would disagree, I believe those are the majority. Steve
On Sat, Jul 09, 2005 at 06:45:38PM +0100, Stephen J. Wilcox wrote:
Still its nice to see all the old kooks still alive and well and not yet locked up in mental homes. I'd better do my part to feed the trolls i guess...
Ok, from what *I* can see, the people arguing *against* the topic are the ones who sound like blathering, insulting idiots (like this post), and the ones on the other side sound calm and rational. But "mental homes" is a touch rough, even for NANOG, no? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Sat, Jul 09, 2005 at 06:45:38PM +0100, Stephen J. Wilcox wrote:
Those who consider ICANN the authority would disagree, I believe those are the majority.
Incidentally, Steve, clearly the USDoC NTIA is *not* in that majority. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
----- Original Message ----- From: "Stephen J. Wilcox" <steve@telecomplete.co.uk> To: "John Palmer (NANOG Acct)" <nanog@adns.net> Cc: <nanog@merit.edu> Sent: Saturday, July 09, 2005 12:45 PM Subject: Re: The whole alternate-root ${STATE}horse
I didnt realise it was that time of year again already, it feels like only a couple months since the last annual alternate root debate.
Still its nice to see all the old kooks still alive and well and not yet locked up in mental homes. I'd better do my part to feed the trolls i guess...
On Sat, 9 Jul 2005, John Palmer (NANOG Acct) wrote:
Please prove that Inclusive Namespace roots put name resolution at risk.
No proof is needed, this is not maths. If there are two roots then a query to each server has the potential to return a different reply. The chance of this happening increases over time plus if an alternate root were to become popular their power to challenge authority if a class were found grows.
The potential, yes, but what Inclusive namespace roots do you know that create such collisions (other than ICANN with its cloning of .BIZ)? What kind of credibility do you think such a root would have if they answered with the wrong set of nameservers for, say .COM. What is technically possible and what actually ocurrs are two different things. I can use a sledgehammer to pound in tent stakes at a refugee camp for victims of the tsunami or I can smash up people's cars with them. Show me how any of the current Inclusive Roots have done these kinds of things. The only example is ICANN and .BIZ.
Client side users, conversely, expect that published addresses by businesses or individuals go to the intended party.
This is the key point, clients and domain owners need this consistency. Read this a few times and consider how you'd feel if $large_provider decided to point your domain name or their competitors domains to their website .. its the same problem.
Introducing fragmented TLDs or the opportunity to supplant the common TLDs places the DNS infrastructure at risk. This is not just FUD -- DNS hijacking in alternate roots has already happened. (But if you had actually read RFC2826, you would already understand this.)
Please post a link or give an example. If you mean .BIZ, I would agree, it was hijacked, but by ICANN, not by any Inclusive Roots. It belonged to AtlanticRoot and ICANN deliberatly created a collision. Collisions cause instability and the biggest one was caused by ICANN.
Those who consider ICANN the authority would disagree, I believe those are the majority.
Steve
Still awaiting facts and examples to prove you point and all I get back is a religious argument. Sigh..... John
On Sat, Jul 09, 2005 at 11:46:11AM -0400, Todd Vierling wrote:
On Wed, 6 Jul 2005 Michael.Dillon@btradianz.com wrote:
1. Security ("man-in-the-middle").
VPNs, SSH tunnels, etc. There are ways to solve this problem.
You would use a VPN or SSH tunnel to do what? That's orthogonal to DNS security issues, and illustrates that you haven't read DNSSEC and/or 2826.
2. Common interoperability.
We do not currently have common interoperability for a whole range of protocols.
So what? DNS is one of the protocols where interoperability is not just desirable, it's MANDATORY.
Businesses and individuals expect that when they publish an e-mail or Web site hostname, that it be theirs and only theirs no matter where on the Internet it is accessed. FQDNs are considered fixed points of entry, and alternate roots put that name resolution at risk. (But if you had actually read RFC2826, you would already understand this.)
I'm going to dive in one more time here. It's not the *root* operators that are the problem -- it's the *TLD* zone operators.
Introducing fragmented TLDs or the opportunity to supplant the common TLDs places the DNS infrastructure at risk. This is not just FUD -- DNS hijacking in alternate roots has already happened. (But if you had actually read RFC2826, you would already understand this.)
"infrastructure at risk". Justify this *far-reaching* statement, please. Show your work.
and I appreciate the IAB's comments, but it was written at a time when we didn't have as much experience with rootless networks as we do now.
The DNS is not a rootless network, so this is a pointless comment.
That response appears to assume facts not in evidence in his comment.
On the flip side, there was quite a bit of experience with alternate DNS roots at the time RFC2826 was created -- AlterNIC, which was run and advocated by people just as blinded by ignorance as you.
Oh wait, your name wouldn't *actually* be Jim Fleming, would it?
<chuckle> Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Sat, 9 Jul 2005, Jay R. Ashworth wrote:
I'm going to dive in one more time here.
It's not the *root* operators that are the problem -- it's the *TLD* zone operators.
Oh, I can certainly agree with that; we've seen some gross abuses of TLDs documented in gory detail right here on the NANOG list. Of course, that too is orthogonal to who provides the delegations in "." -- except that perhaps some misguided souls are, as is relatively common, confusing the two realms.
Introducing fragmented TLDs or the opportunity to supplant the common TLDs places the DNS infrastructure at risk. This is not just FUD -- DNS hijacking in alternate roots has already happened. (But if you had actually read RFC2826, you would already understand this.)
"infrastructure at risk". Justify this *far-reaching* statement, please. Show your work.
AlterNIC overriding .COM and .NET listings, one of the issues leading to its demise. (This was done in addition to the more memorable cache poisoning attacks against INTERNIC.NET.) The risk is uncertainty of name resolution, as the root zone can in fact override N-level records simply by posessing a more specific name. Root servers are queried for the full host (but respond with the NS glue delegation), not just the first component, which allows for such overriding.
Oh wait, your name wouldn't *actually* be Jim Fleming, would it?
<chuckle>
Well, at least some folks remember. 8-) -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
On Sat, Jul 09, 2005 at 01:51:46PM -0400, Todd Vierling wrote:
On Sat, 9 Jul 2005, Jay R. Ashworth wrote:
It's not the *root* operators that are the problem -- it's the *TLD* zone operators.
Oh, I can certainly agree with that; we've seen some gross abuses of TLDs documented in gory detail right here on the NANOG list.
Of course, that too is orthogonal to who provides the delegations in "." -- except that perhaps some misguided souls are, as is relatively common, confusing the two realms.
Indeed.
"infrastructure at risk". Justify this *far-reaching* statement, please. Show your work.
AlterNIC overriding .COM and .NET listings, one of the issues leading to its demise. (This was done in addition to the more memorable cache poisoning attacks against INTERNIC.NET.)
To the extent that you don't call that a criminal aberration -- one that could as easily have happened to one of the root servers currently *taking* the ICANN root zone -- it only affected people who were resolving off that root. That's a pretty small number, and, IMHO, doesn't rise to the level of "placing the infrastructure [of the entire net] at risk".
The risk is uncertainty of name resolution, as the root zone can in fact override N-level records simply by posessing a more specific name. Root servers are queried for the full host (but respond with the NS glue delegation), not just the first component, which allows for such overriding.
And that possibility is any different in the n-root case than in the 1-root case... why?
Oh wait, your name wouldn't *actually* be Jim Fleming, would it?
<chuckle>
Well, at least some folks remember. 8-)
Whoa, yeah. My Linux boxes all run IPv8. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Sat, 9 Jul 2005, Jay R. Ashworth wrote:
"infrastructure at risk". Justify this *far-reaching* statement, please. Show your work.
AlterNIC overriding .COM and .NET listings, one of the issues leading to its demise. (This was done in addition to the more memorable cache poisoning attacks against INTERNIC.NET.)
To the extent that you don't call that a criminal aberration -- one that could as easily have happened to one of the root servers currently *taking* the ICANN root zone -- it only affected people who were resolving off that root. That's a pretty small number, and, IMHO, doesn't rise to the level of "placing the infrastructure [of the entire net] at risk".
Such a "small" detail is such a big problem because entities using the alternate root end up seeing a different view of what should be fixed data, and the details of why they see a different view is normally *hidden from the end user*. So end users are caught unaware of the fact that their communications may be going to someone completely different than intended.
The risk is uncertainty of name resolution, as the root zone can in fact override N-level records simply by posessing a more specific name. Root servers are queried for the full host (but respond with the NS glue delegation), not just the first component, which allows for such overriding.
And that possibility is any different in the n-root case than in the 1-root case... why?
Besides the end user visibility problem above, the 1-root case has a legal and tecnical accountability advantage: if someone were to mess with ".", a LOT of people would notice, and the offending person or entity could be prosecuted (or at least isolated from the net) more quickly and easily. As much as the Utopian ideal of an entity without accountability (such as an alternate root) may sound pleasing, even to me, lack of accountability actually decreases security by the very same means that AlterNIC was able to override 2LDs. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
----- Original Message ----- From: "Todd Vierling" <tv@duh.org> To: "Jay R. Ashworth" <jra@baylink.com> Cc: <nanog@merit.edu> Sent: Saturday, July 09, 2005 12:51 PM Subject: Re: The whole alternate-root ${STATE}horse
On Sat, 9 Jul 2005, Jay R. Ashworth wrote:
I'm going to dive in one more time here.
It's not the *root* operators that are the problem -- it's the *TLD* zone operators.
Oh, I can certainly agree with that; we've seen some gross abuses of TLDs documented in gory detail right here on the NANOG list.
Of course, that too is orthogonal to who provides the delegations in "." -- except that perhaps some misguided souls are, as is relatively common, confusing the two realms.
Introducing fragmented TLDs or the opportunity to supplant the common TLDs places the DNS infrastructure at risk. This is not just FUD -- DNS hijacking in alternate roots has already happened. (But if you had actually read RFC2826, you would already understand this.)
"infrastructure at risk". Justify this *far-reaching* statement, please. Show your work.
AlterNIC overriding .COM and .NET listings, one of the issues leading to its demise. (This was done in addition to the more memorable cache poisoning attacks against INTERNIC.NET.)
Yes, and Eugene was punished for that. Notice that AlterNic really doesn't exist anymore. Repeat after me - COLLISIONS ARE BAD! We all agree with that.
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
John
On Sat, 9 Jul 2005, John Palmer (NANOG Acct) wrote:
Repeat after me - COLLISIONS ARE BAD! We all agree with that.
But you can't avoid collisions with multiple namespaces. This is exactly why Internet needs IANA - to avoid collisions in TLD names, used ip addresses, protocol parameters, etc. What you're doing with separate namespace is as if you took some part of the currently unused IP space and setup your own BGP peering network for those using that space with your own registry, but also accepted routes from Intenet peers on the same router mixing it all up. -- William Leibzon Elan Networks william@elan.net
No William, we are talking about multiple roots, NOT separate namespaces. There is one namespace. There cannot be collisions. Inclusive roots do not create collisions - only ICANN has done that so far. There are people who have a great disagreement about how ICANN is going about its business. There is a large piece of the world that doesn't want ICANN to be the authority. No public RSN that cares about its credibility will create collisions. ----- Original Message ----- From: "william(at)elan.net" <william@elan.net> To: "John Palmer (NANOG Acct)" <nanog@adns.net> Cc: <nanog@merit.edu> Sent: Saturday, July 09, 2005 2:05 PM Subject: Re: The whole alternate-root ${STATE}horse
On Sat, 9 Jul 2005, John Palmer (NANOG Acct) wrote:
Repeat after me - COLLISIONS ARE BAD! We all agree with that.
But you can't avoid collisions with multiple namespaces. This is exactly why Internet needs IANA - to avoid collisions in TLD names, used ip addresses, protocol parameters, etc.
What you're doing with separate namespace is as if you took some part of the currently unused IP space and setup your own BGP peering network for those using that space with your own registry, but also accepted routes from Intenet peers on the same router mixing it all up.
-- William Leibzon Elan Networks william@elan.net
On Sat, 09 Jul 2005 14:52:23 CDT, "John Palmer (NANOG Acct)" said:
No public RSN that cares about its credibility will create collisions.
Ergo, ICANN doesn't care about its credibility, because it created a .BIZ. Except that at the time, the people who had the .BIZ that got collided with had no reason (a MoU, contract, or even a deal over beer) to expect that ICANN wouldn't do such a thing. If you're asserting that the "big players" need be careful of colliding with a TLD in some tiny root you've never heard of, you're opening a *really* nice extortion business model - just start up your own root, cybersquat the first few million likely TLDs, and yell foul and demand a license fee or other damages each time somebody else tries to create that TLD. Either that, or you need to demonstrate that all the roots are cooperating in some clearinghouse a la the way .COM is run - such an arrangement would in fact be a reasonable way to follow RFC2826, as one clearinghouse would maintain the root. Of course, such a clearinghouse isn't actually in evidence, nor is there any obvious reason to believe that one will be creatable... And keep in mind as well that some things aren't done maliciously or even intentionally - things like AS7007 or the time a third of .COM dissapeared because of a disk-full error during the build *just* *happen*. So what happens if the following goes down: Company A in Beijing decides it wants tld .qn--e4r34ew, and goes to Roots-R-Us to register it. Meanwhile, company B in Hong Kong goes to TLDs-for-cheap and registers the same domain. Both roots push their respective updates at 8AM Monday, and hilarity ensues. Discuss the conflict resolution process, citing the aggreements that will be followed.
Actually, many naming and addressing management experts consider that the existence of a root defines a unique namespace. Also, the issue of authority for a namespace is a distinct and separate issue from affection for that authority. Cutler At 03:52 PM 7/9/2005, John Palmer (NANOG Acct) wrote: No William, we are talking about multiple roots, NOT separate namespaces. There is one namespace. There cannot be collisions. Inclusive roots do not create collisions - only ICANN has done that so far. There are people who have a great disagreement about how ICANN is going about its business. There is a large piece of the world that doesn't want ICANN to be the authority. No public RSN that cares about its credibility will create collisions. - James R. Cutler james.cutler@consultant.com
participants (12)
-
bmanning＠vacation.karoshi.com -
Brad Knowles -
James R. Cutler -
Jay R. Ashworth -
John Palmer (NANOG Acct) -
Mark Newton -
Michael.Dillon＠btradianz.com -
Stephen J. Wilcox -
Todd Vierling -
Tony Finch -
Valdis.Kletnieks＠vt.edu -
william(at)elan.net