I belive that the root servers (at least some - F in particular but more would make sense) are using anycast addressing, which makes it possible for there to be many hosts scattered around the globe that all share the same ip address. So, really, there are more than 13 root servers if you're just counting boxes, with (again, at least F) having a presence in more than just one data center.
A quick google brought me to this presentation and it looks good:
http://www.nanog.org/mtg-0310/miller.html
I certainly would consider that hosts doing this - being readvertised via BGP from many different networks - would be about as decentrialized as you could get at the network level. Of course, there still is that nagging political and administrative control that still needs work and Verisign's dns manipulations simply underscore how important it is for administrative control to be distributed as well.
They should only be asked for NS records. That they give out NS referrals in response to questions outside of their authority in their replies, is a courtesy.
Root servers *DO NOT* "resolve some IP's", which more exactingly is to say that they do not accept 'recursive queries' (queries for data outside of their authority). I can explain your example:
The root servers have knowledge of all of the other name servers for all second level domains. So if you ask for 'ns1.foo.com', in reality, that machine is a 'registered host' - a host name that is 'known' and does not go thru the normal recursive dns resolution mechanisam - They are NOT recursively resolving names! Try asking the root for an unregistered nameserver (or any other aribtrary host) and it'll simply give you a referral.If you update your nameserver config files to give 'ns1.foo.com' another address, the roots wont know or care, because these registered hosts have to be updated seperately.
A DNS query for an IP address is a *BAD REQUEST* contrary to what some of these other posters have said. Asking a root server to resolve anything in the first place, is bad - they should only be asked for NS records - and in the second place, an IP address is not a valid domain name (unless ICANN has serripitiously added 256 new top level domains, namely, the numbers 0 thru 255).
Most networks that I've seen, are badly broken this way. The usual problem is that the network in question may use private address space (192.168.1.0/24 for example), but fail to install reverse dns for these addresses, causing delays and other problems when machines try to get the name associated with their ip address or that of a local machine connecting to them. Yes, you heard right - if you use any of the 192.168.x.x, 10.x.x.x, or 172.16-32.x.x addresses, you are broken unless you install dns to resolve for those addresses! This also goes for any ip netblock in general, although most isp's these days are setting up dummy records for their unused ip space that'll cover their customers allocations ok.
You know, there is another way to do this. And that is, to outsmart these oppressive ILEC's by pooling our collective knowledge and BEING PREPARED for their games.
I am right now trying to bring DSL service in to my small community (Willits, California), and I started knowing full well what I was up against. I think it would mean a *lot* to the local community (and it's economy, which has been hard hit by the recession in the timber industry), to actually have a decent high speed Internet service provider that _lives in_ the the community and _is responsive_ to it's needs, and is _willing to invest_ the time, effort and dollars to make it available as widely as possible. Initially, and unfortunately, that means I need to use SBC's (the ILEC in california) wires. I'm ready to do this _today_, but instead I have to keep wasting time with SBC running round and round in circles over this CLEC issue and wether we really need to become one before they will lease us their wire. I don't see it... but because none of us are pooling our resources, I guess i'll have to learn the same as you folks.
http://www.TieDyeNetworks.com - peace, love, and Fast Downloads in the Redwoods!
I am an ISP in Willits, California, a small broadband starved rual community about 120 miles north of San Francisco, and I am going down this road right now with SBC with respect to access to their copper loops, so that I can hot foot the process of providing DSL here.
I've encountered both incompetence ("I don't know what you're talking about") and malice ("You need to be a clec, like north point or covad.") (Gee, weren't those guys driven out of business by your market protectionist and predatory behavior??). Just like the man said, that ILEC's have developed it into an artform, of staying just on this side of acting illegally while at the same time making it as painful as possible to work with them. I have no reason to belive that SBC is going to cooperate with me and will force me to force them to play ball. This is a sad state of affairs.
My community *DESERVES* DSL internet. And my reading of the 96 telecommunications act, combined with the ruby ridge story, tells me that I'm right about this CLEC issue - that it's a smokescreen, to protect the ILEC against real competition. I belive that there is _no legitimate reason_ why I should be forced to become a CLEC in order to lease copper wires. I would be not engaging in any regulated utillity service, I would not be impacting the operation of the telephone network, I would not be imposing any unreasonable engineering or support requirements on the telco. I dont' see any legitimate excuse at all to deny us.
I have access to several locations that have 100 pair cables comming in to them, and the combined loop distance between these sites and the central office and any of our future subscribers, is well within spec of DSL (the advantages of being a small town). We don't need a darn thing in terms of 'services' from SBC - really, we simply need copper loops and we could be providing DSL service here _next week_. Left to their own devices, SBC wouldn't get high speed access here for YEARS, if ever, they just don't care about us. The only real reason why SBC wants you to go the CLEC route, is because they can impose upon you those tremendous legal and regulatory responsabillities, which of course is going to bleed you dry financially. I checked out their CLEC website (https://clec.sbc.com), and being a CLEC partner (cough, cough) gets you all kinds of stuff - access to their internal order entry systems, automated troubleshooting systems, line prequalification systems, automated customer disconnection notification, etc. That kind of stuff might be appropriate for a company doing tens of thousands of circuits per month, but it is not appropriate for us, we're too small and we just want to get the show on the road. I wish to god I could get the assistance of those attorneys who did such a good just job for ruby ridge, we could get precedent set and then the _whole country_ could finally move forward!
Oh yeah - we are http://www.tiedyenetworks.com - Peace, love, and Fast Downloads in the Redwoods!
I had exactly this problem - "Uncompressing kernel....ok, done" and then nothing. In my case, it was a combonation of having a serial console configured and not getting the boot messages, and then also booting from a SCSI disk but not having both scsi adapter supported and 'scsi diskk support' compiled in.
Alan, yesterday on slashdot, there was a reference to an article about FreeBSD where basiclly they came right out and admitted to being snobs and 'not accepting code from just anyone'. The metric in the Linux community seems to be if it's good code and makes sense, include it. Do you agree that this leads to a less-tightly integrated system, or are the BSD guys simply whining because nobody wants BSD and they've finially realised that they need to care what us peon users think after all?
One thing you might not realise too, is that like anything that comes from a University and the people deeply embedded in that culture, is that the focus and emphasis is on the small private clicks that form around the institutions, giving rise to that old adage "It's not what you know but who you know". So in BSD, you need to win popularity contests to get your stuff into the system. In linux, however, you only need to demonstrate the technical validity of your proposal. Thus, BSD lags behind in the development arena and has a pathetically small developer community to support it. I also imagine that the several forks of BSD are largely due to interested developers not being able to win popularity contests and thus being forced to fork off the code base in order to get their own stuff added.
Remember that what linus torvalds did was to capitalize on the Internet and the available talent. And he was wildly sucessful in creating a worldwide development team, which in turn has turned out a tremendous product. BSD can't do that because it's about popularity contests and dysfunctional politics. The artical says that the difference, as if it really means anything, is that BSD developers have degrees and 10 years of experience and are managers in their work, while Linux hackers are all unwashed masses without degrees (loosely interpreted). It said it as if that implies a certain quality of the code that won't be found in Linux. Bullshit. The focus should be on technical merits and not who has the more prestegious paper. And in the Linux world that is most certainly the case.
Linux is a truely open develop model that does not discriminate based on popularity contests or worthless peices of paper. It is not about who your sponsor is or what friends you have on the inside or who owes you favors. It's about technical merit.
I'd like to add that, in my experience, BWMGR does not work as advertised, nor is et interested at all in providing technical support or issuing the various bug fixes needed to make it really work.
Slashdot Mirror
I belive that the root servers (at least some - F in particular but more would make sense) are using anycast addressing, which makes it possible for there to be many hosts scattered around the globe that all share the same ip address. So, really, there are more than 13 root servers if you're just counting boxes, with (again, at least F) having a presence in more than just one data center.
A quick google brought me to this presentation and it looks good:
http://www.nanog.org/mtg-0310/miller.html
I certainly would consider that hosts doing this - being readvertised via BGP from many different networks - would be about as decentrialized as you could get at the network level. Of course, there still is that nagging political and administrative control that still needs work and Verisign's dns manipulations simply underscore how important it is for administrative control to be distributed as well.
Aiee, RFC quoted, killing thread!
They should only be asked for NS records. That they give out NS referrals in response to questions outside of their authority in their replies, is a courtesy.
Oh, no again:
Root servers *DO NOT* "resolve some IP's", which more exactingly is to say that they do not accept 'recursive queries' (queries for data outside of their authority). I can explain your example:
The root servers have knowledge of all of the other name servers for all second level domains. So if you ask for 'ns1.foo.com', in reality, that machine is a 'registered host' - a host name that is 'known' and does not go thru the normal recursive dns resolution mechanisam - They are NOT recursively resolving names! Try asking the root for an unregistered nameserver (or any other aribtrary host) and it'll simply give you a referral.If you update your nameserver config files to give 'ns1.foo.com' another address, the roots wont know or care, because these registered hosts have to be updated seperately.
A DNS query for an IP address is a *BAD REQUEST* contrary to what some of these other posters have said. Asking a root server to resolve anything in the first place, is bad - they should only be asked for NS records - and in the second place, an IP address is not a valid domain name (unless ICANN has serripitiously added 256 new top level domains, namely, the numbers 0 thru 255).
Most networks that I've seen, are badly broken this way. The usual problem is that the network in question may use private address space (192.168.1.0/24 for example), but fail to install reverse dns for these addresses, causing delays and other problems when machines try to get the name associated with their ip address or that of a local machine connecting to them. Yes, you heard right - if you use any of the 192.168.x.x, 10.x.x.x, or 172.16-32.x.x addresses, you are broken unless you install dns to resolve for those addresses! This also goes for any ip netblock in general, although most isp's these days are setting up dummy records for their unused ip space that'll cover their customers allocations ok.
You know, there is another way to do this. And that is, to outsmart these oppressive ILEC's by pooling our collective knowledge and BEING PREPARED for their games.
I am right now trying to bring DSL service in to my small community (Willits, California), and I started knowing full well what I was up against. I think it would mean a *lot* to the local community (and it's economy, which has been hard hit by the recession in the timber industry), to actually have a decent high speed Internet service provider that _lives in_ the the community and _is responsive_ to it's needs, and is _willing to invest_ the time, effort and dollars to make it available as widely as possible. Initially, and unfortunately, that means I need to use SBC's (the ILEC in california) wires. I'm ready to do this _today_, but instead I have to keep wasting time with SBC running round and round in circles over this CLEC issue and wether we really need to become one before they will lease us their wire. I don't see it... but because none of us are pooling our resources, I guess i'll have to learn the same as you folks.
http://www.TieDyeNetworks.com - peace, love, and Fast Downloads in the Redwoods!
I am an ISP in Willits, California, a small broadband starved rual
community about 120 miles north of San Francisco, and I am going down this
road right now with SBC with respect to access to their copper loops, so
that I can hot foot the process of providing DSL here.
I've encountered both incompetence ("I don't know what you're
talking about") and malice ("You need to be a clec, like north point or
covad.") (Gee, weren't those guys driven out of business by your market
protectionist and predatory behavior??). Just like the man said, that ILEC's
have developed it into an artform, of staying just on this side of acting
illegally while at the same time making it as painful as possible to work
with them. I have no reason to belive that SBC is going to cooperate with me
and will force me to force them to play ball. This is a sad state of
affairs.
My community *DESERVES* DSL internet. And my reading of the 96
telecommunications act, combined with the ruby ridge story, tells me that
I'm right about this CLEC issue - that it's a smokescreen, to protect the
ILEC against real competition. I belive that there is _no legitimate reason_
why I should be forced to become a CLEC in order to lease copper wires. I
would be not engaging in any regulated utillity service, I would not be
impacting the operation of the telephone network, I would not be imposing
any unreasonable engineering or support requirements on the telco. I dont'
see any legitimate excuse at all to deny us.
I have access to several locations that have 100 pair cables comming
in to them, and the combined loop distance between these sites and the
central office and any of our future subscribers, is well within spec of DSL
(the advantages of being a small town). We don't need a darn thing in terms
of 'services' from SBC - really, we simply need copper loops and we could be
providing DSL service here _next week_. Left to their own devices, SBC
wouldn't get high speed access here for YEARS, if ever, they just don't care
about us. The only real reason why SBC wants you to go the CLEC route, is
because they can impose upon you those tremendous legal and regulatory
responsabillities, which of course is going to bleed you dry financially. I
checked out their CLEC website (https://clec.sbc.com), and being a CLEC
partner (cough, cough) gets you all kinds of stuff - access to their
internal order entry systems, automated troubleshooting systems, line
prequalification systems, automated customer disconnection notification,
etc. That kind of stuff might be appropriate for a company doing tens of
thousands of circuits per month, but it is not appropriate for us, we're too
small and we just want to get the show on the road. I wish to god I could
get the assistance of those attorneys who did such a good just job for ruby
ridge, we could get precedent set and then the _whole country_ could finally
move forward!
Oh yeah - we are http://www.tiedyenetworks.com - Peace, love, and
Fast Downloads in the Redwoods!
Peace!
I had exactly this problem - "Uncompressing kernel....ok, done" and then nothing. In my case, it was a combonation of having a serial console configured and not getting the boot messages, and then also booting from a SCSI disk but not having both scsi adapter supported and 'scsi diskk support' compiled in.
Alan, yesterday on slashdot, there was a reference to an article about FreeBSD where basiclly they came right out and admitted to being snobs and 'not accepting code from just anyone'. The metric in the Linux community seems to be if it's good code and makes sense, include it. Do you agree that this leads to a less-tightly integrated system, or are the BSD guys simply whining because nobody wants BSD and they've finially realised that they need to care what us peon users think after all?
One thing you might not realise too, is that like anything that comes from a University and the people deeply embedded in that culture, is that the focus and emphasis is on the small private clicks that form around the institutions, giving rise to that old adage "It's not what you know but who you know". So in BSD, you need to win popularity contests to get your stuff into the system. In linux, however, you only need to demonstrate the technical validity of your proposal. Thus, BSD lags behind in the development arena and has a pathetically small developer community to support it. I also imagine that the several forks of BSD are largely due to interested developers not being able to win popularity contests and thus being forced to fork off the code base in order to get their own stuff added.
Remember that what linus torvalds did was to capitalize on the Internet and the available talent. And he was wildly sucessful in creating a worldwide development team, which in turn has turned out a tremendous product. BSD can't do that because it's about popularity contests and dysfunctional politics. The artical says that the difference, as if it really means anything, is that BSD developers have degrees and 10 years of experience and are managers in their work, while Linux hackers are all unwashed masses without degrees (loosely interpreted). It said it as if that implies a certain quality of the code that won't be found in Linux. Bullshit. The focus should be on technical merits and not who has the more prestegious paper. And in the Linux world that is most certainly the case.
Linux is a truely open develop model that does not discriminate based on popularity contests or worthless peices of paper. It is not about who your sponsor is or what friends you have on the inside or who owes you favors. It's about technical merit.
I'd like to add that, in my experience, BWMGR does not work as advertised, nor is et interested at all in providing technical support or issuing the various bug fixes needed to make it really work.