I fully agree. And "tree of life" is a natural way [ha ha] of describing what Darwin came up with. Just straightening the proselyte out on his own religion a bit. And TFA is thoroughly wrong in implying the turn of phrase was original on Darwin's part.
Blame retroviruses; they can take genetic material from one species and insert it into the genome of another thereby creating cross-branches.
A tree is not the same thing as a directed acyclic graph (DAG). What you describe, with cross branches, is a directed acyclic graph—cross branches do not necessarily create cycles in a DAG. A tree is a directed acyclic graph with a unique root node from which there is a unique path to every other node. There are many kinds of directed acyclic graphs that do not have this property.
Darwin didn't come up with the phrase "Tree of Life". It was first used in the Bible in the Book of Revelations describing Heaven.
Uh, no. First, it's the book of "Revelation"; it describes a vision revealed to John. Second, the tree of life is one of the two important trees described in Genesis, in the Garden of Eden, the other being the tree of knowledge of good and evil. The tree of life is also a Kabbalistic construction unifying the ten Sephiroth.
What are you doing to address the concerns raised by various posters that:
Spammers can utilize your system to create TLD DNS entries for arbitrary domains, allowing them to synthesize domains at will to use in spam source addresses.
You are causing numerous unnecessary modifications to the namespace of various TLDs, impacting performance of the TLD registries and nameservers for your own financial gain, at the expense of the performance of the entire Internet infrastructure.
Your reservation system has closed source. Corner conditions may exist that would cause severe degradation of the TLD infrastructure, and we cannot inspect it to identify possible pathologies.
People who search for domains on your homepage are not agreeing to purchase the domain from you, so it is fundamentally unethical for you to prevent them from purchasing such domains elsewhere.
People who object to NSI's practice can easily construct a large distributed system to attack this feature, continuously reserving many pseudorandom domains, thus preventing people with legitimate interest in these domains from registering them via any registrar but NSI. That is, any time the attack happens to reserve a domain someone actually wants, that person has to purchase the domain from NSI. Indeed, NSI itself could foment such an attack as a stealth tactic for garnering registrations, and all this attention may be exactly what NSI desires.
The practice of abusing the add grace period for your financial gain—thrashing the DNS TLDs so you can make a buck—is unethical and dangerous. That you implemented it without consulting IETF or ICANN is clear evidence that you are not competent to operate a registrar, and cannot be trusted with any infrastructure DNS servers. You obviously do not appreciate the distinction between production infrastructure and your own corporate playground, and this is not the first time you've made that clear. I feel strongly that ICANN should revoke any trust vested in your organization to maintain or modify infrastructure.
What are the odds of someone stumbling on these slashdot-user-created domains in particular? I mean, only people coming from slashdot right?
Once all this stuff gets indexed in the search engines, it'll end up being noise that people might follow because the domain name looks like something they're looking for. If people keep looking up the names, this will direct traffic to NSI, which might result in some domain sales.
Another way it may make NSI money is if someone actually wants to purchase a domain one of the attackers happens to have done a lookup on, and can't wait 4 days for it, forcing the buyer to get it through NSI.
Yes, it's funny. No, it's not a good idea. I think the point has been made, and am hopeful that ICANN and the other registrars should be able to succeed in getting NSI to stop in the near future.
However, command-line whois (or web-based whois from somebody who isn't sleazy) should work
The reason I prefer strict DNS over WHOIS of any kind is that, if I'm interested in a domain that turns out to be registered, I don't want to direct WHOIS queries to the current registrar. That registrar might recognize a WHOIS query as legitimate interest in acquiring the domain and subsequently squat (or continue squatting) on it. Periodic WHOIS queries increase a domain's apparent market value for the registrar who currently holds it. This makes it less likely that the registrar will let the domain expire, whereupon I might acquire it at a normal price.
A DNS query, in contrast, has so many potential causes that even if it is logged it doesn't imply any interest in domain acquisition.
Mind you, I only hold a few domains, and I'm not a speculator, but this is the reasoning.
Sure there are many ways to do it. I'm trying to suggest a way that generates a lot of plausible names. Since effective domain names shouldn't have much entropy, relying on an entropy source for them seems like the wrong approach to me.
Harmful for whom?
Harmful for the gTLD registries and nameservers that will be inundated, and conceivably DOSed with updates.
Why not simply run John the Ripper with a small dictionary and the --stdout option? That will produce a list of names that look like real candidates and operate at great speed without depleting your entropy pool.
Not that I advocate it—it's a silly and possibly harmful exercise, IMHO. I'm just saying.
Quite so—all trade secrets should be considered trade secrets, and already are. But if one's business case is that sensitive to the domain name, it prolly ain't worth much, really.
In effect, between all the mistyped URLs, spammers forging domains speculatively, dead links to defunct domains, web portals misinterpreting things that look like URLs as links, web spiders, etc. this is already going on. DNS is a fairly high-noise medium. A database of failed DNS lookups would require some statistical analysis before it would be useful to a squatter.
Again, all NSI needs to do to blunt that attack is put a captcha on the query page. Meanwhile, you might be stressing the TLD nameservers by doing such a thing (updates are more expensive than queries). This can affect everyone—and I mean everyone—not just NSI.
Vote with your wallet. There are plenty of registrars. If you have domains registered at NSI, transfer them elsewhere. Some registrars even give you a free year with a transfer.
you walk into a store and see a jacket you like. you tell the clerk you want that jacket and the clerk puts it behind the counter for you.
It's more like: you walk into a store and see a jacket you like. You tell the clerk you are interested in that jacket and the clerk puts it behind the counter for you. You leave to check the price at a competitor's store, but by the time you get there the clerk has already called all the competing businesses and instructed them not to sell you that jacket, to which they agree.
An automated attack is easy for them to defeat by simply putting a captcha in front of the query system. I suspect they already have captcha code to handle actual purchases, so this is very little effort for them.
On the contrary, Network Solutions is effectively monetizing the domains by forcing buyers to purchase them at Network Solutions' inflated prices.
Furthermore, this concept of protection would only make sense if you thought consumers were searching for a domain both on Network Solutions' lookup system and on that of an another unethical competitor. But why would consumers do that? One lookup is sufficient, and by definition, you know that one lookup occurred on your site, so it's already unlikely that a competitor will have the opportunity. The notion that you're protecting anyone doesn't wash.
The article you referred to talks about ISPs selling failed domain lookups logged on their DNS servers, not ones they sniffed off the wire. dig... +trace doesn't consult ISP nameservers; it starts at the root servers and finds an authoritative chain to the target domain, so that scenario is not relevant.
Except that you might get a lack of response when a domain is registered because someone has registered it but not put any DNS records behind it.
Yes, there are rare cases where you might not see a response, at which point you can go ahead and try to register the domain and perhaps fail. But most registrars throw in their own parking nameservers at registration time automatically, so it's pretty unusual to find a name that is in a registry but has no DNS records. The more likely scenario is when a domain is in HOLD status after expiring.
That plus your ISP can still sniff that request anyway (which apparently some of them do).
If you know of cases where ISPs are speculatively squatting on domains based on sniffed DNS lookups, please enlighten us. Certainly there are scenarios where even a DNS lookup could trigger squatting or tasting; after all, a GTLD server operator might be colluding. The noise level in DNS is so high, though, that they would be thrashing the TLD registries pretty heavily if they were doing this.
Whether it's NSI or some other registrar doing it, this has been a known issue for a long time. The solution is not to use WHOIS. Instead follow DNS from the root and see if it goes anywhere. E.g.:
when I read "SQL injection attack" I think "AddSlashes()"
A better approach is to use parameterized prepared statements. Attempting to escape strings is prone to error, since sometimes you need them escaped and sometimes you need them unescaped and it's easy to use the wrong version. Parameters to prepared statements are handled internally by the RBDMS client library so there is structurally no way for interpolated content to break context.
The only time this is difficult is when you need to form a complex query with structure that depends on what parameters were supplied by the client (e.g. adding a constraint for each of a number of optional form fields).
Certainly. But my question is whether there is information indicating that this ion mask outperforms epoxy or other conformal coatings in this respect?
Re stickiness: any decent epoxy coating is not sticky at all. Re heat transfer: I wonder at what temperature the ion mask would be degraded.
Also, for potential cell phone applications, can this effectively protect the diaphragms on the microphone and speaker? Most everything else in a cell phone is already pretty easy to waterproof, if a manufacturer had any real incentive to do so.
Slashdot Mirror
I fully agree. And "tree of life" is a natural way [ha ha] of describing what Darwin came up with. Just straightening the proselyte out on his own religion a bit. And TFA is thoroughly wrong in implying the turn of phrase was original on Darwin's part.
Ie it is not a "directed, acyclic graph".
Unfortunately it has 'cycles'.
Blame retroviruses; they can take genetic material from one species and insert it into the genome of another thereby creating cross-branches.
A tree is not the same thing as a directed acyclic graph (DAG). What you describe, with cross branches, is a directed acyclic graph—cross branches do not necessarily create cycles in a DAG. A tree is a directed acyclic graph with a unique root node from which there is a unique path to every other node. There are many kinds of directed acyclic graphs that do not have this property.
Uh, no. First, it's the book of "Revelation"; it describes a vision revealed to John. Second, the tree of life is one of the two important trees described in Genesis, in the Garden of Eden, the other being the tree of knowledge of good and evil. The tree of life is also a Kabbalistic construction unifying the ten Sephiroth.
The practice of abusing the add grace period for your financial gain—thrashing the DNS TLDs so you can make a buck—is unethical and dangerous. That you implemented it without consulting IETF or ICANN is clear evidence that you are not competent to operate a registrar, and cannot be trusted with any infrastructure DNS servers. You obviously do not appreciate the distinction between production infrastructure and your own corporate playground, and this is not the first time you've made that clear. I feel strongly that ICANN should revoke any trust vested in your organization to maintain or modify infrastructure.
Once all this stuff gets indexed in the search engines, it'll end up being noise that people might follow because the domain name looks like something they're looking for. If people keep looking up the names, this will direct traffic to NSI, which might result in some domain sales.
Another way it may make NSI money is if someone actually wants to purchase a domain one of the attackers happens to have done a lookup on, and can't wait 4 days for it, forcing the buyer to get it through NSI.
Yes, it's funny. No, it's not a good idea. I think the point has been made, and am hopeful that ICANN and the other registrars should be able to succeed in getting NSI to stop in the near future.
The reason I prefer strict DNS over WHOIS of any kind is that, if I'm interested in a domain that turns out to be registered, I don't want to direct WHOIS queries to the current registrar. That registrar might recognize a WHOIS query as legitimate interest in acquiring the domain and subsequently squat (or continue squatting) on it. Periodic WHOIS queries increase a domain's apparent market value for the registrar who currently holds it. This makes it less likely that the registrar will let the domain expire, whereupon I might acquire it at a normal price.
A DNS query, in contrast, has so many potential causes that even if it is logged it doesn't imply any interest in domain acquisition.
Mind you, I only hold a few domains, and I'm not a speculator, but this is the reasoning.
Good point, and I stand corrected. Also, the clerk is an asshole.
Reforming the DisGrace Period by Larry Seltzer, 2008/01/08. Covers domain tasting and the current stance of ICANN and the registries.
Sure there are many ways to do it. I'm trying to suggest a way that generates a lot of plausible names. Since effective domain names shouldn't have much entropy, relying on an entropy source for them seems like the wrong approach to me.
Harmful for the gTLD registries and nameservers that will be inundated, and conceivably DOSed with updates.
Why not simply run John the Ripper with a small dictionary and the --stdout option? That will produce a list of names that look like real candidates and operate at great speed without depleting your entropy pool.
Not that I advocate it—it's a silly and possibly harmful exercise, IMHO. I'm just saying.
Quite so—all trade secrets should be considered trade secrets, and already are. But if one's business case is that sensitive to the domain name, it prolly ain't worth much, really.
In effect, between all the mistyped URLs, spammers forging domains speculatively, dead links to defunct domains, web portals misinterpreting things that look like URLs as links, web spiders, etc. this is already going on. DNS is a fairly high-noise medium. A database of failed DNS lookups would require some statistical analysis before it would be useful to a squatter.
Again, all NSI needs to do to blunt that attack is put a captcha on the query page. Meanwhile, you might be stressing the TLD nameservers by doing such a thing (updates are more expensive than queries). This can affect everyone—and I mean everyone—not just NSI.
Vote with your wallet. There are plenty of registrars. If you have domains registered at NSI, transfer them elsewhere. Some registrars even give you a free year with a transfer.
It's more like: you walk into a store and see a jacket you like. You tell the clerk you are interested in that jacket and the clerk puts it behind the counter for you. You leave to check the price at a competitor's store, but by the time you get there the clerk has already called all the competing businesses and instructed them not to sell you that jacket, to which they agree.
Well, obviously, because it's the second hit when you search for it on Google.
An automated attack is easy for them to defeat by simply putting a captcha in front of the query system. I suspect they already have captcha code to handle actual purchases, so this is very little effort for them.
On the contrary, Network Solutions is effectively monetizing the domains by forcing buyers to purchase them at Network Solutions' inflated prices.
Furthermore, this concept of protection would only make sense if you thought consumers were searching for a domain both on Network Solutions' lookup system and on that of an another unethical competitor. But why would consumers do that? One lookup is sufficient, and by definition, you know that one lookup occurred on your site, so it's already unlikely that a competitor will have the opportunity. The notion that you're protecting anyone doesn't wash.
The article you referred to talks about ISPs selling failed domain lookups logged on their DNS servers, not ones they sniffed off the wire. dig ... +trace doesn't consult ISP nameservers; it starts at the root servers and finds an authoritative chain to the target domain, so that scenario is not relevant.
Yes, there are rare cases where you might not see a response, at which point you can go ahead and try to register the domain and perhaps fail. But most registrars throw in their own parking nameservers at registration time automatically, so it's pretty unusual to find a name that is in a registry but has no DNS records. The more likely scenario is when a domain is in HOLD status after expiring.
If you know of cases where ISPs are speculatively squatting on domains based on sniffed DNS lookups, please enlighten us. Certainly there are scenarios where even a DNS lookup could trigger squatting or tasting; after all, a GTLD server operator might be colluding. The noise level in DNS is so high, though, that they would be thrashing the TLD registries pretty heavily if they were doing this.
Whether it's NSI or some other registrar doing it, this has been a known issue for a long time. The solution is not to use WHOIS. Instead follow DNS from the root and see if it goes anywhere. E.g.:
dig the-domain-you-want.com. +traceA better approach is to use parameterized prepared statements. Attempting to escape strings is prone to error, since sometimes you need them escaped and sometimes you need them unescaped and it's easy to use the wrong version. Parameters to prepared statements are handled internally by the RBDMS client library so there is structurally no way for interpolated content to break context.
The only time this is difficult is when you need to form a complex query with structure that depends on what parameters were supplied by the client (e.g. adding a constraint for each of a number of optional form fields).
Yes, this is just like OpenDNS except the IPs are 208.67.222.222 and 208.67.220.220. No account is necessary to use OpenDNS.
That's not the only issue—it's also important to know at what temperature and rate of thermal transfer the coating itself will be damaged.
Certainly. But my question is whether there is information indicating that this ion mask outperforms epoxy or other conformal coatings in this respect?
Re stickiness: any decent epoxy coating is not sticky at all. Re heat transfer: I wonder at what temperature the ion mask would be degraded.
Also, for potential cell phone applications, can this effectively protect the diaphragms on the microphone and speaker? Most everything else in a cell phone is already pretty easy to waterproof, if a manufacturer had any real incentive to do so.