That's just the problem, though. The majority of computer owners do not own what they perceive as a complex mess of interconnected software components. They've purchased an appliance that lets them check their e-mail, type up documents and play games.
Requiring these types of owners to apply packet filters or install some other form of software is excessive.
If a product is being used for these types of purposes without the knowledge or consent of the owner, that implies a fault with the product. If the vendor is continuing to pump out these things with full knowledge that they can and will be abused in the majority of their default installations, that vendor is negligent and needs to change some things at a fundamental level or stop selling the product.
This isn't correct. In this case (as is usual for "web bugs"), the image is hosted on an entirely different server. Security policies restrict JavaScript and cookies to the server hosting the requested page. Since these images are on another server, cookies set via this page (or via JavaScript) could not be sent or interact in any with this image on another server.
However, you could use JavaScript to add parameters like screen solution or other interesting bits to a 1x1 pixel URI and make that request.
I know the document discusses this, but I don't know that I buy the explanation. The spec says a URN should be persistent, and since we don't want to enforce persistency we go off and create something new?
So now when I want to come up with a new way to label information internally, I have two avenues that are now, for most intents and purposes, competitors. If I want a persistent label (for my own definition of persistency, since either way, these are still my labels), I can go with URN or info at my discretion. If I don't want persistency, and want to be anal about my interpretation of a URN, I'm sort of "encouraged" to go with "info".
It just seems counter-productive to create something brand new when a URN is probably going to be good enough. Maybe we just need to use urn:dyn or urd: or urt: instead of urn: if we want to make it very clear that the namespace underneath that will be dynamic.
It just bugs me when standards bodies go off and start considering two different implementations of something that overlap 99% in purpose.
Am I missing something? Is the persistency thing really that much of a blocker that a URN is so inappropriate that something else entirely needs to be invented?
If an attacker breaks into a web server or some other application, even if that application is secured to the point that his privileges are limited, exploits like this will allow him to increase those privileges.
In many US states, even this speed limit (any limit under the state's maximum) is "soft" in that if you can convince a judge that you were exceeding it safely, such as a temporary excess when passing, or when no other traffic is present, you can avoid being found guilty.
But I totally agree and don't care for any law designed to allow the executive branch to enforce it discriminately.
Got an e-mail from some random company the next day telling me the server had been down and could they interest me in their monitoring packages. I'd never even noticed them in the logs, which kinda impressed me.
I had a similar incident, but instead of quietly monitoring, this company decided to run some stress tests (purportedly requested by some employee here whose name he couldn't find). Fortunately our servers were able to handle it, with little degradation, but when your inbound traffic jumps up by a factor of 10, you tend to notice these things.
After I tracked down the company, they blithely agreed to stop their testing and offered to sell us the results and maybe examine our environment to see how we could make it perform better (as if the effects I observed suggested our environment wasn't optimized as well as it could be). Unbelievable.
While I could care less about "background noise" traffic to my web sites (after all, it's a public web site, right?), I really take issue with a) unsolicited spam (which is what you received); and b) veiled "attacks" designed to make me think I need someone else's services.
So if a script kiddie out there is trying to test his hostname parsing code in his latest DDoS tools, and tries to use a hostname that he knows doesn't exist, would he be liable for the damage his scriptz cause when that hostname actually does resolve to a Verisign IP address?
It really sounds like Verisign wants traffic destined for every mistyped or invalid hostname. I say let them have it. Surely they're aware that the Internet is not just the web.
Right now I think NASA and us Americans are not smart enough to do these things. We'd probably attempt to do them anyone just to stroke our egos and risk more lives.
Are you trolling?
Don't you know its not profitable to do these things? So why waste the money?
What do you spend your money on? Food, shelter, heat, electricity. Things for your immediate survival. This would be similar to your tax money funding police, fire departments, maybe hospitals, your city's utility infrastructure, etc. Certainly very necessary.
You might also spend a bit on cable TV, maybe a CD or two, tickets to see a play. Things to soothe your senses, maybe enlighten you a bit. Sometimes it's nice to earmark some of your tax money to go towards a local festival of some kind, or a big gala on a major holiday. Those are good things for your government to try and do, right?
And let's say you're everyone's ideal kind of guy and you donate regularly to some charities. We like our governments to do things at a grand scale that our "ideal guy" would do, so we have programs like welfare, health care and social security out there to keep people alive and productive.
Now you're getting advanced in your years, and you look back and ask yourself, "What have I accomplished with my life? How have I contributed to society to advance the human race?"
Why can't our government focus some of its citizens willpower and resources towards accomplishing something new, instead of funneling all of those resources back into the people?
The human civilization is like a giant machine, and it's a little depressing that that machine is running at full power and is only succeeding at shaking things up and generating heat.
If we used DNS domains like they were designed to be used, this could be an easy-to-correct problem.
Any entity registering in.com must clearly be a commercial entity with no problem in giving out their business address, contact number, etc.
Any entity registering in.net is a service provider, and should have all sufficient information to contact that provider for connectivity or abuse issues.
Any entity registering in.org is a non-profit organization, and should post any contact information that they'd otherwise be required to post as part of their charter.
We have a '.name' now (which personally I think should have been '.nom'), for personal users. I think it's perfectly reasonable to expect that individuals will not want to put any contact information there. I also think it's perfectly reasonable for an ISP's contact information to be exposed in its place, though.
Basically, just apply privacy requirements to the intent of the domain name. If regular Joes want to register a.com, they need to expect to be treated like a commercial entity.
Subdomains under a country code would need to be addressed by the countries in question.
PVR is an acronym, not an abbreviation. For the purposes of popping up some little help text describing the expansion of "PVR", either would work, but for non-visual user agents, or user agents that want to do something a little more intelligent than this, it's important to distinguish between the two, as they are fundamentally different.
Most of the problems I regularly see/have revolve around noise. The biggest issues:
Being noisy on the phone. Use the handset and/or a headset at all times. Use the speakerphone sparingly (if at all) only when you need to share the phone briefly with others that are in a cube. Regular meetings like this should be done in a conference room. Also be aware that unless you have a really cheap phone, you can speak softly and still be heard quite clearly by the other party. Don't feel like you have to shout. (On a related topic, be sure your phone and/or headset has a Mute button, and your people are trained to use it.)
Set your ringer down to the lowest setting that will get your attention. Generally speaking, you should not need to run to get back to your cube to answer a call, so there's little reason to have your ringer set so loud that you can hear it across the floor. Some people (like myself) are happy turning their ringer off and using the visual indicator (flashing red light) to inform them of an incoming call.
Turn your cell phone ringer off, or keep it attached to you somehow. Do not leave your cell phone ringer on with your phone unattended. The same goes for pagers and PDA's. This is basically an extreme example of the previous issue. After a while, the cutesy ring tone seriously starts grating on everyone's nerves. (Especially when you get a persistent caller that doesn't think you are without your phone; they may call 2 or 3 times in a row thinking you just aren't hearing the ring. Very obnoxious.)
Get headphones for your PC, or turn the volume down to the bare minimum for you to hear it. People can usually tolerate the occasional error beep, but constant "You've got mail!" or "Uh-oh!" or "I'm sorry, Dave, I'm afraid I can't do that." sounds are irritating as well when repeated. Likewise for mp3's or.wav files people feel they have to pass around because they're amusing.
If you're a fast typer, consider getting a quiet keyboard. Typing is usually something that you can get used to as background noise, but if you have a loud typer, that might not be possible.
Consider getting overhead fans for your cubicles. These aren't used so much for blowing air as they are for generating white noise. This can be handy for drowning out neighboring conversations (or your own) or other noises.
The rest of your sentence seems to have gotten chopped off:
CLECs have a harder time getting access to ILEC networks.... where the market already hosts at least three carriers that own their own equipment.
If you have three carriers in there that own their own lines and equipment, it stands to reason that the barrier to entry into that market is not as significant as it is in other areas, where there may be only one ILEC and where the addition of another company's lines is prohibitively expensive.
The goal here isn't to help the new guy at the expense of the old guys, it's to help the new guy break into a market that the old guys hold pretty solidly. If the old guys already have a significant amount of competition in a market, what good does it do for consumers to keep letting more in?
Some of your points have a touch of validity, but there are some flaws in your thinking that I wanted to address.
First, Qwest would charge the competitive ISP a sign-up charge for each customer,
The first thing you should think about here is that Qwest probably leases to resellers using a different strategy than what they use to market to their own customers.
If you were a telephone company, and you were required to lease service to a competitor, wouldn't you hit them with every cost as that cost was incurred? When you sign up a new DSL customer, you have to perform some amount of work to get that customer set up with DSL service. It is logical to bill the reseller for that work, and to proceed billing him monthly an amount that reflects your maintenance.
Either way, the DSL provider (Qwest or the reseller) eats money at install-time. Qwest may "waive" that setup fee for a 1- or 2-year contract, figuring they would recoup those costs as the user's service continues. Your DSL reseller is also perfectly free to eat that cost for the same contractual arrangement. They just may not choose to. This isn't Qwest being evil, it's your reseller choosing to sell their service differently.
Meaning that whenever your DSL goes down, if you've signed up with an independent ISP, your support would be pretty much useless.
Don't confuse your ISP service with your DSL service! The phone company is there soley to provide physical-layer (DSL) and/or link-layer (ATM) service. The ISP is usually on an ATM end-point and provides IP service. Even with the ILECs, the ISP is a separate entity, and while they may work harder to keep the appearance of one smoothly-running operation, the ISP side of the house has no more control over the DSL side than your independent ISP does.
In both cases, the ISP will tell you that a DSL problem has to be resolved by the telco. The telco will tell you IP service issues will need to be resolved by the ISP.
Perhaps a better solution is building dark fiber on government money and then having counties charge any phone company lease access fees.
I agree with you here. I'd like to see some thought given to running that "last mile copper" like any other public utility, like water and sewer lines. Let that utility sell service on those lines to whoever wants to use them.
Re:Common names are what advertisements say they a
on
DNSSEC: Good Enough?
·
· Score: 1
the same ones ICANN trots out (well, except you didn't mention their favorite "without central control nothing could possibly work!")...because my arguments are independent from theirs.
It should be obvious that most top-level domains (such as, for example,.pepsi) would not generate enough income through name sales to support themselves; so simple economics would suffice (in the long run) to weed out non-viable top-level domains.
I'm not sure I understand how you're coming to this conclusion. Your.pepsi example is a good one. Are you suggesting that ICANN (or whoever their successor is) have a requirement that a TLD owner re-sell? What expenses do you think a TLD owner has at this point that a major corporation doesn't already have funding for?
If Pepsi had the opportunity to register a 'pepsi' top-level domain, even if they were "required" to resell underneath 'pepsi', throwing down a few million dollars or so for hardware and operating expenses for that TLD is nothing compared to what they throw at online expenses.
So hell yah, I'd buy some shiny new servers, drop the 'pepsi' TLD on them, and if required, start up a marketing campaign to give away joe-smith.loves.pepsi hostnames.
What company wouldn't?
What expenses do you think they would have that would make this unattractive or impractical?
Not so. Several people have gone so far as to predict that the total number of names would decrease if the namespace was freed.
You're looking at the gtld-servers, not the root-servers. The root servers today just answer for the top-level domains. These are a static list (today), and those servers can be optimized to just spewing out those results. By "freeing" the top-level namespace, every subsidiary of every company is going to want one, and even if a few are weeded out because they don't have the infrastructure (which I'm not sure will ever be the case, since there's a lot of money to be made from this idea), this will "fatten" DNS at the root level, even if it thins DNS out at the second-level.
Basically, the DNS hierarchy will become top-heavy. You've got to shift resources around to accomodate that shift in load, away from the gtld-servers and towards the root-servers.
But it does seem logical that overall, the number of registered names would decrease. As more TLDs come available, corporations begin to realize that they're not going to be able to buy every name that's going to be remotely similar to their own. The ".com" craze will wither as www.example.com stops being the standard locator mechanism.
Assuming something else has stepped in to be that locator.
The only LDAP server that would scale to the degree
LDAP (like X.500 and DNS) does support delegation, though. You don't need to set up one monolithic LDAP farm here, just one big enough to cover your organization. Get your locality to set up delegation properly and it's just as distributed as DNS.
The big scalability problems you see with DNS revolve around that silly second-level name, where everyone and their mother has to own every conceivable name dot-com. Once that goes away in favor of a more reasonable hierarchy, scalability becomes easier as things become more distributed.
But you still could be right; LDAP or X.500 might not be the appropriate thing here. But DNS (at least in its current form) isn't either.
I believe it's custom, but you're absolutely right: it's enormous overhead.
The Desktop Support folks I'm sure chipped in, though, as it's pretty useful in their arena to be able to see what and what versions you have installed. If an important patch comes out for some obscure piece of supported software, they can pretty easily identify everyone that needs it.
Re:You're still pushing revisionist history
on
DNSSEC: Good Enough?
·
· Score: 1
The organization that became ICANN certainly existed before the type of search engine you are talking about
Yes, in the form of a technical body, not a political one.
At one time, there was a transition from a technically-oriented Internet to a commercially-oriented one. The point where marketers started giving DNS hostnames IP weight is the point where DNS became inappropriate for IP-weighted naming. DNS came about from technical requirements and was intended to solve just those requirements, not to be an AOL keyword. That's the big issue here.
There's nothing "revisionist" about what I'm saying. Perhaps you're just misinterpreting or maybe I'm not making my point clearly enough.
It's all about the mindset of the users. Hostnames and URLs were fine for geeks. We respected the hierarchy of DNS and understood what the components of a URL meant. These things are not fine for Joe Public, which should be obvious when you watch the name grab for example.com, and the allowance for abbreviated URLs in the form of example.com. The public wants AOL keywords, and neither DNS nor URLs in general are fit for that purpose.
It almost sounds like you're suggesting that the DNS hierarchy be freed (like at the top level). If I'm understanding you, this would give anyone and everyone the ability to register any top-level domain they wanted. There have been lots of articles and messages discussing this and it all boils down to the fact that DNS would quickly become very top-heavy. Everyone would want their identifier to be at the top-level (making it just like an AOL keyword; no dot-com!). Litigation would abound and the root servers would have to be beefed up several orders of magnitude. I don't see how this would solve anything. But perhaps I am misinterpreting.
In my opinion, the best solution to this problem is to give the public a simple way to associate common names and marks to their official Internet entities. LDAP and X.500 would do this splendidly. At least there, a search for "Apple" will give you a better selection than the general assumption that a company named "Apple" is at "apple.com". Keep DNS out of the public's eyes and ICANN's politics and DNS-based litigation will disappear.
Just as a counter-example, I work for a major telecommunications company, and we are extremely sensitive about our software licenses. There is software installed on our PC's that simply does a tally of the installed applications and compares that with known purchased licenses.
It's fairly trivial at that point to identify how many licenses are in use, who's installing unlicensed software (which might just be an indication that more licenses are needed, but usually is just grounds for an inquiry), etc.
That isn't to say that software houses like Microsoft don't perform audits of some kind, but having an extensive record-keeping system like this allows us to stay in the clear.
I think many (most?) major corporate software contracts usually have a clause in there allowing them to audit you for compliance. No raids are necessary in these cases, unless you can't quite slip something by them during the audit. Big companies tend to prefer to handle non-compliance matters discretely (i.e. pay larger penalties to avoid a public raid/investigation). That's probably why you don't usually hear about them.
The Internet started off as a network for the technical. Hostnames were fine then, as ways to identfy hosts on the Internet. There weren't many DNS domains and things were done properly in a hierarchy. URLs were invented with the web, but since everything was still targeted to the technically-oriented, this was fine. Geeks didn't mind passing URLs around, and generally they weren't needed if all of your content was reasonably compact such that things could be linked together. There wasn't a lot of content around that you couldn't find by following a couple of links from your local portal.
At this point, AOL is starting to shine and the marketing world revolves around AOL keywords. Companies paid for the privilege of having an AOL keyword map to content provided by them.
If you're of the impression that URLs (as they were used at the time) were created with the intent of slapping them on TV commercials (e.g. http://www.marketing.example.com/product-literatur e/new-widget-2000), you're mistaken. The intent of the designers, very early on, was to push for search engines to do the job of locating a piece of content, while the URI would identify that content.
It just turned out that search engines did a fairly shitty job of reliably sending users to the content they were hunting for. This, combined with the fact that there was no "authoritative" search engine designed to locate official URIs (or even DNS domains) for an organization, caused web browsers to start allowing abbreviated URIs to be used (making assumptions about the missing pieces), which allowed marketers to abbreviate URLs until the second-level domain itself was the only significant piece. We now have something akin to AOL's keywords, and suddenly everyone has to have example.com, example-widgets-2000.com, and every other product name, service mark and trade mark.com they can get their hands on, much to the annoyance of others that may have a very legitimate claim to them.
But instead of having AOL decide what was and was not a legitimate keyword for the organization requesting it, we have litigation successfully applying IP weight to DNS hostnames!
DNS was intended simply to provide a memorable, convenient label for an IP address. It's used for a bit more than that today, but as a locator service, DNS is inappropriate. We still need a better kind of search engine (perhaps a real directory) and need to stop relying on the fact that "example.com" will take me to the most widely-known company with "Example" in its name. It's a sucky state of affairs, and even if it works today in a pinch, the immense overhead required to make it that way is nothing other than a lawyer's dream.
Re:The problem is that DNS is trying to be Google
on
DNSSEC: Good Enough?
·
· Score: 1
This "works" because these companies have gone to the courts to wrestle these domains away from other (frequently quite legitimate) holders.
You're picking some fairly obvious examples. The case of the White House in particular is only obvious because you've been there before. If I want to see information about the presidency, and did not know that the "White House" was the title of his Internet presence, I might try a large number of combinations before coming across that one.
Why does Apple Computers, Inc. get apple.com? Why not Apple Supermarkets or some other company with Apple in their name?
DNS is used as a search engine because in a large number of the cases (not all), companies have litigated to allow that to happen. The very fact that litigation is even needed suggests that DNS is being used for something it's not designed for.
What's really needed is a directory that associates real-world names (official company names and/or trade/service marks) with DNS domains. SRV records in DNS could then point you to that domain's primary HTTP server. Users don't necessarily need to even see a URL or a hostname at that point.
Search engines can do the rest. But let's stop bloating IP laywers by continuing to misuse DNS like this.
TLS (the new SSL standard) can just as easily use PGP-based keys instead of X.509 certificates. Browsers don't support that, clearly, but the protocol itself does.
That's kind of an exaggeration. There's no overhaul. It's just the addition of a couple of new record types and the added procedural step of signing your zone when you make changes to it. This can all be automated, if you trust the security of your automation. Requests and replies look the same as they always did unless you're DNSSEC-aware and make the extra step to ask for DNSSEC-related records.
Do you think we have this "requisite technology" even today? Are you aware that the "test pilot" programs are still very much alive and full of eager participants?
Are you suggesting that we put a hold on this type of research until computers reach the point where they can react just as well as a real human pilot?
Slashdot Mirror
That's just the problem, though. The majority of computer owners do not own what they perceive as a complex mess of interconnected software components. They've purchased an appliance that lets them check their e-mail, type up documents and play games.
Requiring these types of owners to apply packet filters or install some other form of software is excessive.
If a product is being used for these types of purposes without the knowledge or consent of the owner, that implies a fault with the product. If the vendor is continuing to pump out these things with full knowledge that they can and will be abused in the majority of their default installations, that vendor is negligent and needs to change some things at a fundamental level or stop selling the product.
This isn't correct. In this case (as is usual for "web bugs"), the image is hosted on an entirely different server. Security policies restrict JavaScript and cookies to the server hosting the requested page. Since these images are on another server, cookies set via this page (or via JavaScript) could not be sent or interact in any with this image on another server.
However, you could use JavaScript to add parameters like screen solution or other interesting bits to a 1x1 pixel URI and make that request.
I know the document discusses this, but I don't know that I buy the explanation. The spec says a URN should be persistent, and since we don't want to enforce persistency we go off and create something new?
So now when I want to come up with a new way to label information internally, I have two avenues that are now, for most intents and purposes, competitors. If I want a persistent label (for my own definition of persistency, since either way, these are still my labels), I can go with URN or info at my discretion. If I don't want persistency, and want to be anal about my interpretation of a URN, I'm sort of "encouraged" to go with "info".
It just seems counter-productive to create something brand new when a URN is probably going to be good enough. Maybe we just need to use urn:dyn or urd: or urt: instead of urn: if we want to make it very clear that the namespace underneath that will be dynamic.
It just bugs me when standards bodies go off and start considering two different implementations of something that overlap 99% in purpose.
Am I missing something? Is the persistency thing really that much of a blocker that a URN is so inappropriate that something else entirely needs to be invented?
If an attacker breaks into a web server or some other application, even if that application is secured to the point that his privileges are limited, exploits like this will allow him to increase those privileges.
In many US states, even this speed limit (any limit under the state's maximum) is "soft" in that if you can convince a judge that you were exceeding it safely, such as a temporary excess when passing, or when no other traffic is present, you can avoid being found guilty.
But I totally agree and don't care for any law designed to allow the executive branch to enforce it discriminately.
Got an e-mail from some random company the next day telling me the server had been down and could they interest me in their monitoring packages. I'd never even noticed them in the logs, which kinda impressed me.
I had a similar incident, but instead of quietly monitoring, this company decided to run some stress tests (purportedly requested by some employee here whose name he couldn't find). Fortunately our servers were able to handle it, with little degradation, but when your inbound traffic jumps up by a factor of 10, you tend to notice these things.
After I tracked down the company, they blithely agreed to stop their testing and offered to sell us the results and maybe examine our environment to see how we could make it perform better (as if the effects I observed suggested our environment wasn't optimized as well as it could be). Unbelievable.
While I could care less about "background noise" traffic to my web sites (after all, it's a public web site, right?), I really take issue with a) unsolicited spam (which is what you received); and b) veiled "attacks" designed to make me think I need someone else's services.
So if a script kiddie out there is trying to test his hostname parsing code in his latest DDoS tools, and tries to use a hostname that he knows doesn't exist, would he be liable for the damage his scriptz cause when that hostname actually does resolve to a Verisign IP address?
It really sounds like Verisign wants traffic destined for every mistyped or invalid hostname. I say let them have it. Surely they're aware that the Internet is not just the web.
Right now I think NASA and us Americans are not smart enough to do these things. We'd probably attempt to do them anyone just to stroke our egos and risk more lives.
Are you trolling?
Don't you know its not profitable to do these things? So why waste the money?
What do you spend your money on? Food, shelter, heat, electricity. Things for your immediate survival. This would be similar to your tax money funding police, fire departments, maybe hospitals, your city's utility infrastructure, etc. Certainly very necessary.
You might also spend a bit on cable TV, maybe a CD or two, tickets to see a play. Things to soothe your senses, maybe enlighten you a bit. Sometimes it's nice to earmark some of your tax money to go towards a local festival of some kind, or a big gala on a major holiday. Those are good things for your government to try and do, right?
And let's say you're everyone's ideal kind of guy and you donate regularly to some charities. We like our governments to do things at a grand scale that our "ideal guy" would do, so we have programs like welfare, health care and social security out there to keep people alive and productive.
Now you're getting advanced in your years, and you look back and ask yourself, "What have I accomplished with my life? How have I contributed to society to advance the human race?"
Why can't our government focus some of its citizens willpower and resources towards accomplishing something new, instead of funneling all of those resources back into the people?
The human civilization is like a giant machine, and it's a little depressing that that machine is running at full power and is only succeeding at shaking things up and generating heat.
If we used DNS domains like they were designed to be used, this could be an easy-to-correct problem.
.com must clearly be a commercial entity with no problem in giving out their business address, contact number, etc.
.net is a service provider, and should have all sufficient information to contact that provider for connectivity or abuse issues.
.org is a non-profit organization, and should post any contact information that they'd otherwise be required to post as part of their charter.
.com, they need to expect to be treated like a commercial entity.
Any entity registering in
Any entity registering in
Any entity registering in
We have a '.name' now (which personally I think should have been '.nom'), for personal users. I think it's perfectly reasonable to expect that individuals will not want to put any contact information there. I also think it's perfectly reasonable for an ISP's contact information to be exposed in its place, though.
Basically, just apply privacy requirements to the intent of the domain name. If regular Joes want to register a
Subdomains under a country code would need to be addressed by the countries in question.
PVR is an acronym, not an abbreviation. For the purposes of popping up some little help text describing the expansion of "PVR", either would work, but for non-visual user agents, or user agents that want to do something a little more intelligent than this, it's important to distinguish between the two, as they are fundamentally different.
even IE (granted, 5+) will display it, although withouth the nice dashed underline Mozilla puts out.
This could be fixed by adding this to your CSS style sheet:
acronym { border-bottom: dotted 1pt }
The rest of your sentence seems to have gotten chopped off:
CLECs have a harder time getting access to ILEC networks.... where the market already hosts at least three carriers that own their own equipment.
If you have three carriers in there that own their own lines and equipment, it stands to reason that the barrier to entry into that market is not as significant as it is in other areas, where there may be only one ILEC and where the addition of another company's lines is prohibitively expensive.
The goal here isn't to help the new guy at the expense of the old guys, it's to help the new guy break into a market that the old guys hold pretty solidly. If the old guys already have a significant amount of competition in a market, what good does it do for consumers to keep letting more in?
Some of your points have a touch of validity, but there are some flaws in your thinking that I wanted to address.
First, Qwest would charge the competitive ISP a sign-up charge for each customer,
The first thing you should think about here is that Qwest probably leases to resellers using a different strategy than what they use to market to their own customers.
If you were a telephone company, and you were required to lease service to a competitor, wouldn't you hit them with every cost as that cost was incurred? When you sign up a new DSL customer, you have to perform some amount of work to get that customer set up with DSL service. It is logical to bill the reseller for that work, and to proceed billing him monthly an amount that reflects your maintenance.
Either way, the DSL provider (Qwest or the reseller) eats money at install-time. Qwest may "waive" that setup fee for a 1- or 2-year contract, figuring they would recoup those costs as the user's service continues. Your DSL reseller is also perfectly free to eat that cost for the same contractual arrangement. They just may not choose to. This isn't Qwest being evil, it's your reseller choosing to sell their service differently.
Meaning that whenever your DSL goes down, if you've signed up with an independent ISP, your support would be pretty much useless.
Don't confuse your ISP service with your DSL service! The phone company is there soley to provide physical-layer (DSL) and/or link-layer (ATM) service. The ISP is usually on an ATM end-point and provides IP service. Even with the ILECs, the ISP is a separate entity, and while they may work harder to keep the appearance of one smoothly-running operation, the ISP side of the house has no more control over the DSL side than your independent ISP does.
In both cases, the ISP will tell you that a DSL problem has to be resolved by the telco. The telco will tell you IP service issues will need to be resolved by the ISP.
Perhaps a better solution is building dark fiber on government money and then having counties charge any phone company lease access fees.
I agree with you here. I'd like to see some thought given to running that "last mile copper" like any other public utility, like water and sewer lines. Let that utility sell service on those lines to whoever wants to use them.
the same ones ICANN trots out (well, except you didn't mention their favorite "without central control nothing could possibly work!") ...because my arguments are independent from theirs.
.pepsi) would not generate enough income through name sales to support themselves; so simple economics would suffice (in the long run) to weed out non-viable top-level domains.
.pepsi example is a good one. Are you suggesting that ICANN (or whoever their successor is) have a requirement that a TLD owner re-sell? What expenses do you think a TLD owner has at this point that a major corporation doesn't already have funding for?
It should be obvious that most top-level domains (such as, for example,
I'm not sure I understand how you're coming to this conclusion. Your
If Pepsi had the opportunity to register a 'pepsi' top-level domain, even if they were "required" to resell underneath 'pepsi', throwing down a few million dollars or so for hardware and operating expenses for that TLD is nothing compared to what they throw at online expenses.
So hell yah, I'd buy some shiny new servers, drop the 'pepsi' TLD on them, and if required, start up a marketing campaign to give away joe-smith.loves.pepsi hostnames.
What company wouldn't?
What expenses do you think they would have that would make this unattractive or impractical?
Not so. Several people have gone so far as to predict that the total number of names would decrease if the namespace was freed.
You're looking at the gtld-servers, not the root-servers. The root servers today just answer for the top-level domains. These are a static list (today), and those servers can be optimized to just spewing out those results. By "freeing" the top-level namespace, every subsidiary of every company is going to want one, and even if a few are weeded out because they don't have the infrastructure (which I'm not sure will ever be the case, since there's a lot of money to be made from this idea), this will "fatten" DNS at the root level, even if it thins DNS out at the second-level.
Basically, the DNS hierarchy will become top-heavy. You've got to shift resources around to accomodate that shift in load, away from the gtld-servers and towards the root-servers.
But it does seem logical that overall, the number of registered names would decrease. As more TLDs come available, corporations begin to realize that they're not going to be able to buy every name that's going to be remotely similar to their own. The ".com" craze will wither as www.example.com stops being the standard locator mechanism.
Assuming something else has stepped in to be that locator.
The only LDAP server that would scale to the degree
LDAP (like X.500 and DNS) does support delegation, though. You don't need to set up one monolithic LDAP farm here, just one big enough to cover your organization. Get your locality to set up delegation properly and it's just as distributed as DNS.
The big scalability problems you see with DNS revolve around that silly second-level name, where everyone and their mother has to own every conceivable name dot-com. Once that goes away in favor of a more reasonable hierarchy, scalability becomes easier as things become more distributed.
But you still could be right; LDAP or X.500 might not be the appropriate thing here. But DNS (at least in its current form) isn't either.
I believe it's custom, but you're absolutely right: it's enormous overhead.
The Desktop Support folks I'm sure chipped in, though, as it's pretty useful in their arena to be able to see what and what versions you have installed. If an important patch comes out for some obscure piece of supported software, they can pretty easily identify everyone that needs it.
The organization that became ICANN certainly existed before the type of search engine you are talking about
Yes, in the form of a technical body, not a political one.
At one time, there was a transition from a technically-oriented Internet to a commercially-oriented one. The point where marketers started giving DNS hostnames IP weight is the point where DNS became inappropriate for IP-weighted naming. DNS came about from technical requirements and was intended to solve just those requirements, not to be an AOL keyword. That's the big issue here.
There's nothing "revisionist" about what I'm saying. Perhaps you're just misinterpreting or maybe I'm not making my point clearly enough.
It's all about the mindset of the users. Hostnames and URLs were fine for geeks. We respected the hierarchy of DNS and understood what the components of a URL meant. These things are not fine for Joe Public, which should be obvious when you watch the name grab for example.com, and the allowance for abbreviated URLs in the form of example.com. The public wants AOL keywords, and neither DNS nor URLs in general are fit for that purpose.
It almost sounds like you're suggesting that the DNS hierarchy be freed (like at the top level). If I'm understanding you, this would give anyone and everyone the ability to register any top-level domain they wanted. There have been lots of articles and messages discussing this and it all boils down to the fact that DNS would quickly become very top-heavy. Everyone would want their identifier to be at the top-level (making it just like an AOL keyword; no dot-com!). Litigation would abound and the root servers would have to be beefed up several orders of magnitude. I don't see how this would solve anything. But perhaps I am misinterpreting.
In my opinion, the best solution to this problem is to give the public a simple way to associate common names and marks to their official Internet entities. LDAP and X.500 would do this splendidly. At least there, a search for "Apple" will give you a better selection than the general assumption that a company named "Apple" is at "apple.com". Keep DNS out of the public's eyes and ICANN's politics and DNS-based litigation will disappear.
Just as a counter-example, I work for a major telecommunications company, and we are extremely sensitive about our software licenses. There is software installed on our PC's that simply does a tally of the installed applications and compares that with known purchased licenses.
It's fairly trivial at that point to identify how many licenses are in use, who's installing unlicensed software (which might just be an indication that more licenses are needed, but usually is just grounds for an inquiry), etc.
That isn't to say that software houses like Microsoft don't perform audits of some kind, but having an extensive record-keeping system like this allows us to stay in the clear.
I think many (most?) major corporate software contracts usually have a clause in there allowing them to audit you for compliance. No raids are necessary in these cases, unless you can't quite slip something by them during the audit. Big companies tend to prefer to handle non-compliance matters discretely (i.e. pay larger penalties to avoid a public raid/investigation). That's probably why you don't usually hear about them.
Search engines existed long before ICANN.
r e/new-widget-2000), you're mistaken. The intent of the designers, very early on, was to push for search engines to do the job of locating a piece of content, while the URI would identify that content.
The Internet started off as a network for the technical. Hostnames were fine then, as ways to identfy hosts on the Internet. There weren't many DNS domains and things were done properly in a hierarchy. URLs were invented with the web, but since everything was still targeted to the technically-oriented, this was fine. Geeks didn't mind passing URLs around, and generally they weren't needed if all of your content was reasonably compact such that things could be linked together. There wasn't a lot of content around that you couldn't find by following a couple of links from your local portal.
At this point, AOL is starting to shine and the marketing world revolves around AOL keywords. Companies paid for the privilege of having an AOL keyword map to content provided by them.
If you're of the impression that URLs (as they were used at the time) were created with the intent of slapping them on TV commercials (e.g. http://www.marketing.example.com/product-literatu
It just turned out that search engines did a fairly shitty job of reliably sending users to the content they were hunting for. This, combined with the fact that there was no "authoritative" search engine designed to locate official URIs (or even DNS domains) for an organization, caused web browsers to start allowing abbreviated URIs to be used (making assumptions about the missing pieces), which allowed marketers to abbreviate URLs until the second-level domain itself was the only significant piece. We now have something akin to AOL's keywords, and suddenly everyone has to have example.com, example-widgets-2000.com, and every other product name, service mark and trade mark.com they can get their hands on, much to the annoyance of others that may have a very legitimate claim to them.
But instead of having AOL decide what was and was not a legitimate keyword for the organization requesting it, we have litigation successfully applying IP weight to DNS hostnames!
DNS was intended simply to provide a memorable, convenient label for an IP address. It's used for a bit more than that today, but as a locator service, DNS is inappropriate. We still need a better kind of search engine (perhaps a real directory) and need to stop relying on the fact that "example.com" will take me to the most widely-known company with "Example" in its name. It's a sucky state of affairs, and even if it works today in a pinch, the immense overhead required to make it that way is nothing other than a lawyer's dream.
This "works" because these companies have gone to the courts to wrestle these domains away from other (frequently quite legitimate) holders.
You're picking some fairly obvious examples. The case of the White House in particular is only obvious because you've been there before. If I want to see information about the presidency, and did not know that the "White House" was the title of his Internet presence, I might try a large number of combinations before coming across that one.
Why does Apple Computers, Inc. get apple.com? Why not Apple Supermarkets or some other company with Apple in their name?
DNS is used as a search engine because in a large number of the cases (not all), companies have litigated to allow that to happen. The very fact that litigation is even needed suggests that DNS is being used for something it's not designed for.
What's really needed is a directory that associates real-world names (official company names and/or trade/service marks) with DNS domains. SRV records in DNS could then point you to that domain's primary HTTP server. Users don't necessarily need to even see a URL or a hostname at that point.
Search engines can do the rest. But let's stop bloating IP laywers by continuing to misuse DNS like this.
TLS (the new SSL standard) can just as easily use PGP-based keys instead of X.509 certificates. Browsers don't support that, clearly, but the protocol itself does.
with a complete overhaul of the system.
That's kind of an exaggeration. There's no overhaul. It's just the addition of a couple of new record types and the added procedural step of signing your zone when you make changes to it. This can all be automated, if you trust the security of your automation. Requests and replies look the same as they always did unless you're DNSSEC-aware and make the extra step to ask for DNSSEC-related records.
Do you think we have this "requisite technology" even today? Are you aware that the "test pilot" programs are still very much alive and full of eager participants?
Are you suggesting that we put a hold on this type of research until computers reach the point where they can react just as well as a real human pilot?
Did you even click on the link the original poster provided? It might prove to be enlightening.
remember it's legally MY money ...at least the part you didn't have to pay to taxes.