5 Years After Major DNS Flaw Found, Few US Companies Have Deployed Long-term Fix 313
alphadogg writes "Five years after the disclosure of a serious vulnerability in the Domain Name System dubbed the Kaminsky bug, only a handful of U.S. ISPs, financial institutions or e-commerce companies have deployed DNS Security Extensions (DNSSEC) to alleviate this threat. In 2008, security researcher Dan Kaminsky described a major DNS flaw that made it possible for hackers to launch cache poisoning attacks, where traffic is redirected from a legitimate website to a fake one without the website operator or end user knowing. While DNS software patches are available to help plug the Kaminsky hole, experts agree that the best long-term fix is DNSSEC, which uses digital signatures and public-key encryption to allow websites to verify their domain names and corresponding IP addresses and prevent man-in-the-middle attacks. Despite the promise of DNSSEC, the number of U.S. corporations that have deployed this added layer of security to their DNS server is minuscule."
DNSSEC is not the best long term fix (Score:4, Informative)
DNSSEC is a flaw too! Once I watched a keynote from Daniel J. Bernstein at FISL pointing out all the flaws that make DNSSEC vulnerable. So he pointed to a better solution called DNSCurve: http://en.wikipedia.org/wiki/DNSCurve
Re: (Score:3)
Furthermore see Moxie Marlinspike's criticisms of DNSSEC:
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ [thoughtcrime.org]
About 2/3 way down the page.
Re: (Score:1)
He doesn't get it. People who tout SSL keys in DNSSEC are very aware of the hierarchical nature of the DNSSEC trust relations and who we would be trusting if we used DNSSEC to distribute SSL keys. The point is that we're already trusting the very same people now, in addition to the CAs, and they're not even using trustworthy DNS yet. When you get a certificate from a no-frills CA, you only need to be able to receive mail at one of a few local parts under the domain that you want the certificate for. Bam, ev
Not a criticism of DNSSEC (Score:2)
That isn't a criticism of DNSSEC. That is a criticism of using DNSSEC for things other than DNS resolution. Domain names and IP addresses have to be allocated in a centrally managed fashion, so to avoid conflicts. DNS already has a hierarchical design by nature and DNSSEC simply makes it more secure.
SSL key distribution/validation on the other hand doesn't have to be centrally managed, so adopting a hierarchical control structure like DNSSEC for that task is a suboptimal solution. In fact the problems in th
Re: (Score:2)
In fact the problems in the CA system we currently have directly stem from such a hierarchical trust scheme. We would be much better of going with a truly distributed system for SSL key validation.
I'm unconvinced. (I'm particularly unconvinced by the handwave-assert-jedi-mind-trick style of argument there, but that's by-the-by.) The fundamental problem is that it is very hard to work out if the assertions in a public certificate are true; all you can tell is that the information was digitally signed by someone or something. With a web of trust model, either you have non-transitive trust (which totally doesn't scale at all!) or you have transitive trust, in which case all it takes is for one person to
Re: (Score:2)
We need both secure communications and validation that the returned entries haven't been modified by the server itself.
Re: (Score:1)
Having delved into both deeply, implementing DNSCurve in one server and partially having implemented DNSSEC elsewhere, I can give you a better comparison.
DNSCurve secures the channel between a recursive DNS cache and upstream authoritative servers. It does not attempt to secure the client->cache channel, although there have been related proposals (modifications of the same basic guts DNSCurve had) to secure that channel as well. DNSCurve is designed for a world where you implicitly trust your cache. E
Re: (Score:1)
DNSSEC was designed around real world constraints, not the mythical world where every resolver can talk to authoritative servers directly or only through trusted recursive servers. Yes, there are ISP that force you to use their name servers.
DNSSEC is designed to cope with untrusted authoritative servers. Most people don't have the resources to provide the servers necessary for fault tolerance. With DNSCurve you have to trust those operators to not change the data as any change they make can go undetecte
Re: (Score:2)
Slides from a Bernstein talk [cr.yp.to]
A quote:
Summary so far:
DNSSEC does nothing to improve DNS availability.
Neither does DNSCurve.
DNSSEC allows astonishing levels of DDoS amplification, damaging Internet availability.
Which is not a problem of DNSSEC per say but a basic problem of DNS. It is also solvable. It just requires will to deploy the solutions.
DNSSEC does nothing to improve DNS privacy.
This was a explicit non goal of DNSSEC.
DNSSEC, even with NSEC3, leaks private DNS data.
No more than DNS leaks private data.
Sweden Innovates (Score:5, Informative)
Some respected members of our community dismiss DNSSEC. This video of DJB presents an opinion: DJB at 27C3 [vimeo.com]
Re:Dutch Innovate (Score:2)
Why choose this instead of powerdnssec? I strongly suggest the dnssec training at http://www.dnsseccourse.nl/en/player.html [dnsseccourse.nl] (flash) to improve one's understanding of the dnssec protocol. And powerdns to implement it http://doc.powerdns.com/powerdnssec-auth.html [powerdns.com]
BTW dnssec adoption is amongst the highest for .nl in absolute numbers of domains, simply because there is a bounty for every domain signed. If you have a few hundred of domains the costs to implement are lower than the discount given till mid 2014
Re: (Score:2)
Re: (Score:1)
Nobody is using them? 1/5 of the .nl domains are registered DNSSEC domains:
http://xs.powerdns.com/dnssec-nl-graph/ [powerdns.com]
Re: (Score:1)
Math fail detected: 250*10^6 domains, 5*10^6 .nl, 10^6 .nl with dnssec. So atleast 0.4% of all domains are dnssec:
.nl is in the 5 top of most used country TLDs. .nl is used for about 70% of the domains targetting the dutch market. So dnssec implementation is huge for the local market. And while it still might not be perfect, it is better than just plain DNS.
5/250/5 == 0.004 * 100% == 0.4%
Re: (Score:2)
Re: (Score:1)
Like I said, for the local market dnssec presence is huge, and last time I checked NLD is still part of the real world and it still has some influence on it (especially considering its size).
But .com has everything in place to do dnssec. So if an owner of a .com wants to get dnssec support, they should get a dutch dns provider, there are many that give the customer the option to activate dnssec.
Re: (Score:2)
If you have a few hundred of domains the costs to implement are lower than the discount given till mid 2014 == profit for implementing dnssec
I'm assuming there's some kind of catch in there so that it's not worthwhile for someone to register a few thousand new domains and then implement DNSSEC on them.
Re: (Score:1)
No catch, just a discount per domain registered for dnssec (0.28 EUR/year). I have about 1k .nl domains, I spend a few days figuring out what dnssec was about, how to implement, test and maintain it. Activated it on the corporate domain, some personal and a couple of test domains and waited 2 months to see if there were problems (none). So now it is active for all domains saving us 420 EUR till the discount ends in 2014-06. For us it was not enough to cover the expense of my time, but this had to be implem
Re: (Score:1)
videos? Does noone know how to rite anymore?
Aargh - the next fucker is telling me to look at some flash shit!
Re: (Score:1)
If you just kept reading instead of getting distracted by flash, you'd have seen the next link point to human readable text explaining (briefly) how dnssec works and how to implement it for a specific named. I just have to hope you read past flash this time.
Re: (Score:2)
If I need to watch a nine-part training video to understand DNS, then someone has fucked up DNS. That is bullshit.
Basic rule of computer security (Score:3)
Many potentially targeted organizations will not spend the time and money to make the necessary changes without prodding. I've seen this in payment security too: A lot of companies are shocked and dismayed when they find out that they are supposed to store credit card numbers in some way other than in plaintext in a database accessible to anyone with the single database login that everyone in the company has.
The only thing that will prod them is experiencing a cost of doing nothing that is higher than the cost of implementing the solution.
I deployed it at our ISP recursive servers (Score:5, Interesting)
It broke access to several DNSSEC enabled websites that were misconfigured. After a few months of support problems where we suggested the websites fix their issues and they ignored it, it was requested by management that we turn it off.
It's a very bad design as it stands now. It's unable to return any error but NX Domain for DNSSEC errors for reasons of backword compatibility, which is stupid since you need a DNSSEC enabled resolver to make the request.
It also has an incredibly steep learning curve that even experienced public key administrators face problems with.
Re: (Score:1)
Re: (Score:2)
This. I recently set up a new name server and had to disable it for similar reasons.
Re: (Score:2)
Would either the parent or GP like to list some sites that were broken with DNSSEC? There are some decent tools to test DNSSEC queries, so I'm surprised the DNS admins for the broken zones have left it broken. There's not really any half-assed zone signing with DNSSEC, you either sign the entire zone or you don't.
Re: (Score:2)
And there is the little problem that in the long run, its certificate system is just as broken as the SSL cert system is now. My guess is it is not worth the effort at all.
Re: (Score:1)
"its certificate system is just as broken as the SSL cert system is now"
Can you explain this? DNSSEC hasn't got much common with the SSL cert system. There is only 1 root authority, the weak point during a key change. Each domain/tld has their own (multiple) keys. tld and domains should regenerate the short Zone Signing Keys fairly often (a couple of weeks), while the bigger Key Signing Keys should be regenerated about once in a year. If a tld is compromised it only has to create a new KSK, individual domai
Re: (Score:2)
Too many people in there. Somebody will either mess up or be corrupt. A PKI only works in practice if there is a single CA or a very small number of CAs under tight control. Ignoring the non-technological angle is just incompetent.
Re: (Score:1)
But there are no CAs in DNSSEC. There are only public/private keypairs under control of the owner of the domain.
www.example.com. has 3 pairs/signatures to check:
example.com. tells the com. authority what it's public KSK is.
com. tells the root zone what it's public KSK is.
The public KSK of the root is known by all people/software that want to check dnssec signatures (the weak point since how do you securely distribute and update that one?).
Re: (Score:2)
The public KSK of the root is known by all people/software that want to check dnssec signatures (the weak point since how do you securely distribute and update that one?).
The usual way with PKI is to have two identities involved in the root. One, the master, has a public key very widely known and with a very long life, and only ever used to validate the "operational key"; the master private key is kept offline in a safe somewhere. Perhaps with armed guards or something like that. The operational key is what is used to validate child domains, and as such is in use a lot more and so is more exposed. On the other hand, you can generate new ones (with only the hassle of the arme
Re: (Score:2)
And that makes com a CA. Or how do you think the signature of com gets onto the public key of example.com? Magic?
Re: (Score:1)
"Or how do you think the signature of com gets onto the public key of example.com? Magic?"
It doesn't. And you are confusing a web of trust with CA, it's like PGP. com. can only tell a dnssec user what it thinks the public KSK of example.com. is. That should have been communicated in a secure way to com. It is oneway trust between direct parent-child relations in the dns tree.
Re: (Score:2)
Well, if your assertion is that "people are a problem", you're not the first to make that observation. [goodreads.com].
It's a little-considered fact that 100% of insider crime is committed by insiders.
Short of extincting the human race, I don't see a good solution. Maybe we should not fixate on the insolubles?
Re: (Score:2)
Indeed. The problem I see with things like DNSSEC is that it implies trustworthiness that may well not be there, hence I understand why people are not bothering with it. (Aside from it being another protocol monster form a really clueless tram...) It is also generally not needed for things like remote access, just use 2-sided authentication.
Re: (Score:1)
Except the largest cable ISP in the US, Comcast, has DNSSEC resolvers enabled for customers by default, and they manage to deal with these problems.
They even track and publish informaiton of (large) failing domains and in the backend work with website owners to notify them of the deficiancies. As a Comcast customer, I notify the Comcast DNS folks whenever I have DNSSEC problems, as they have a large amount of clout and will use it to notify website owners.
More large ISPs need to get on board - when we have
Re: (Score:2)
We beat Comcast to the punch by about a year. I'm happy that they turned it on and can afford to support it, but 90% of the customers you have are dumb and don't care why it doesn't work from your ISP, they just care that it works at Starbucks and doesn't work at their house.
Being a huge monopoly has an advantage when it comes to telling customers to pack it up when they have DNS issues. I too am a comcast customer and I run my own resolver (for flexibility, not because they implemented DNSSEC)
All the dom
Re: (Score:2)
It also has an incredibly steep learning curve that even experienced public key administrators face problems with.
There's a way to do it in the name server itself, but here's a way for newbies:
1. in named.conf.local, change file "example.org.zone"; to file "example.org.zone.signed";
2. where you would do rndc reload example.org after a change, you instead do zonesigner --usensec3 -zone example.org. example.org && rndc reload example.org
3. read the key-signing key zonesigner created, log in to your registrar, add a DS record by pasting data from that file
4. if you want the keys to expire (zonesigner's default), s
Dutch solution (Score:2)
SIDN (the maintainer of .nl) offers a small discount to domains that use DNSSEC. This was sufficient motivation for a few large hosting companies to enable DNSSEC across all their domains. In just a few days a fifth of all Dutch domains switched over. By now 26% of the .nl domains (1.381.790 out of 5.153.408) use DNSSEC.
And do you know why it's not widely deployed? (Score:2)
Because the standards are a pain in the ass and most implementations are needlessly complex.
Re: (Score:1)
Re:And do you know why it's not widely deployed? (Score:4, Insightful)
Wrong actually. Security works best when it's simple. Make it too complex, or needlessly complex, and you open yourself up for implementation flaws.
Security implementation should only be as complex as needed. Added complexity only serves to compromise the security you are trying to achieve in the first place.
Re: (Score:3)
Agreed. Implementing DNSSEC is a royal pain in the ass for the authoritative server operator. If it was easy, many would have done it.
Additionally, your domain registrar must support DNSSEC to list the digest records or even public keys with the registry so they can be listed in the TLD-root zone. Once you sign a domain, you cannot transfer the domain to a non-DNSSEC-implementing registrar.
Re: (Score:2)
Of course you can always un-sign your zone. But the idea is that we all should sign our zones to prevent cache poisoning or MITM DNS responses or ISP filtering/wildcarding, etc.
Just like most mail server admins have enabled SPF via simple TXT records, only a few of those have implemented DKIM which requires signing each outbound email.
I do appreciate the beauty of a crazy chaotic and somewhat democratic process to create new standards (IETF/RFC) and implement them laissez-faire style on an as-needed basis.
Re: (Score:2)
What? When you transfer a domain, you usually KEEP the existing nameservers. It's often not wise to use DNS provided by your registrar -- because then when transferring the domain, you need to pre-copy the zone to a new DNS provider.
Yes, you can move the DNS zone from a set of nameservers to another set of authoritative servers, and reducing TTLs for the SOA and NS records are advisable before making that change. However, the registry operators almost always set 48 hour TTLs on the set of authoritative nam
Re: (Score:2)
Indeed. Security is even more dependent on simplicity and clarity than reliability is. Today, we have not even really mastered software reliability and then some people think a complex security mechanism is a good idea? Talk about really not getting it.
DNS is not a security mechanism... (Score:4, Insightful)
If your security depends on DNS working, you are screwed anyways. That is likely the main reason nobody uses DNSSEC: It does solve the wrong problem.
1. The sane way for remote access it is to require 2-sided authentication on connection, making DNSSEC entirely redundant.
2. For the open web, things are a bit differently, but there you can land on a malicious page any time and the only solution for that is a not vulnerable browser or a secure browsing environment.
There is also the small issue that DNSSEC is badly borked and a nightmare to install and maintain. In addition, the other PKI (SSL certs) is badly broken, and there is really no reason the DNSSEC PKI would fare any better if widely deployed. In the long run, it is very likely that DNSSEC is just a waste of time and effort.
Re: (Score:2)
2-sided authentication was mandated in the early IPv6 specs by the IPSec mechanism. Sun offered an alternative, SKIP.
Since then, both have been ported to IPv4.
IPSec is occasionally used by VPN clients, but that's about it. Most VPN clients are run on laptops or other portable devices, often over a wireless link. This is where Sun SKIP was stronger than IPSec, which is ideal for a wired network but gets noisy when you've links that aren't guaranteed stable and error-free.
Regardless, neither is used for meani
Re: (Score:2)
And this is relevant how? IPsec is known to be another protocol monster by clueless designers. How IPsec ever passes the IETF process is a mystery to me. Numerous people must have messes up simultaneously.
TLS (as in OpenVPN, for example) and SSH for UNIX provides a much better basis for 2-sided authentication, and both are in widespread use.
Re: (Score:2)
TLS vulnerability on Slashdot frontpage today.
SSH is of dubious value as it encrypts only select channels, whereas the remaining channels may contain sufficient information to pose a significant vulnerability.
Give me something that WORKS, for Pete's sake, and not this backyard crap.
Re: (Score:1)
The problem with IPv6 adoption is its design, not politics. It was designed as a replacement instead of IPv4 backward-compatible extension. An administrator and end-users have to go through hoops to make this garbage work, and that's why nobody wants to. Why should/would they? IPv6 should have been designed such that neither administrators, nor end-users would have to do much to upgrade.
Re: (Score:2)
IPv4 is intrinsically incapable of being secured. So, if you want to design a secure IP protocol, you cannot have one that is backwards-compatible.
IPv4 is also necessarily fragmented - there is no correlation between IP address and location within the network, leading to bloat in router tables, inefficient routing decisions, excessive latency and greater vulnerability to MitM attacks via router poisoning.
IPv4 requires manual configuration, whereas IPv6 is autoconfigurable by design.
IPv4 has support for IP M
"Major flaw" is a tricky term (Score:2)
Re: (Score:2)
There are few reports of people flying planes into office blocks. People changed behavior, not because there was a reason, but because it was highly visible.
There are many reports of drunk driving fatalities every day. (More die in road accidents per day than have died in terrorist attacks in the past decade.) Nobody changes their behavior because these deaths are NOT highly visible.
People don't give a shit about risk assessment (and aren't capable of it anyway), people only care about the emotional, visibl
Re: (Score:2)
Regardless, my intended point could be phra
Re: (Score:2)
Most of the vulnerabilities we live with are stupid and are only there because humans are incapable of assessing risk. (Those times I refer to myself as an elf, it is because I completely disavow any association with such monstrous stupidity and there are no existent homo sapien subspecies recognized that I could otherwise label myself as. As it is, I am debating whether to lobby the scientific establishment on nomenclature because there's bugger all evidence of any wisdom amongst the humans I've encountere
Re: (Score:2)
humans are incapable of assessing risk
Well that's not true. Humans assess risk all the time. For example, I drove today even though I know there is a chance I could get in a fatal accident. Just because the assessment of others doesn't agree with your assessment doesn't mean they are stupid or wrong.
Re: (Score:2)
First, look up the research and don't base your arguments on Anecdotal Evidence (even your own). The peer-reviewed research says they are stupid and wrong, therefore they are stupid and wrong until there is sufficient evidence to reject that hypothesis. Given your use of Anecdotal Evidence, it is clear that such a rejection may take a while.
Second, I am old enough to be tired of the utter ignorance of the world around me. I've been deep into science for longer than most Slashdotters have been alive. Hell, I
DNSSEC is a PITA (Score:1)
And the Dans are both tools (Kaminsky and Bernstein). And to the guy who suggested hosts files with nasty scripts copying things to and fro, ummm... NO. Sounds like some of the horror stories I've heard of how things are cobbled together at a certain large Seattle-based internet retailer, and it's the kind of hair-brained idea a DevOps fan might dream up.
Quick thoughts from a DNS implementer (Score:2)
Really quickly:
Oi (Score:1)
DNSSEC has nothing to do with the Kaminsky attack.
The Kaminsky attack took advantage of what was essentially bad randomness in DNS resolver implementations.
DNSSEC solves the problem of DNS being plaintext (and consequently vulnerable to man-in-the-middle attacks) in the first place. If you want to call that a "vulnerability", it's one that's been around (and known) for as long as DNS; I guess ~30 years? Current internet culture requires more security so DNSSEC throws a layer of cryptography on top of tradit
DDOS problem (Score:2)
My DNS provider was planning to deploy DNSSEC signing several years ago, but they still haven't.
They claim the reason is that since DNSSEC responses are 75x the size of vanilla DNS responses, this makes DNSSEC providers more vulnerable to DDOS attacks.
Re: (Score:2)
Re: (Score:2)
APK - what's to stop someone poisoning one of the source hosts files you use to generate yours? Like, for example, adding an entry for google.com which points to a drive-by infection site?
Re: (Score:2)
Hmm. That's a lot of sources, any one of which could be compromised at any time.
P.S. in-addr.arpa PTR records are delegated from the root nameservers just like A records - doing reverse lookups doesn't buy you much in terms of security, if you're worried about hijacked DNS.
Re: (Score:2)
I'm not sure you understand how DNS works - the reverse entries are delegated to the IP space owners, so it's just as likely that the in-addr.arpa records are being poisoned, and so your reverse lookup check doesn't buy you much. It's better than not checking, but a well organised poisoning attack will be modifying PTR records to cover SSL full-circle checks anyway.
In fact, you're still trusting that DNS is sound to check your hosts files are coming from the right places, and then adding further vulnerabili
Re: (Score:2)
1) Symantec is the only one of those sources I would even remotely trust, and I'd still be checking every single entry, even with them.
2) You _are_ relying on "ON A WORLD FULL OF UNPATCHED DNS SERVERS", unless you only ever visit the _exact_ hostnames _specifically_ entered in your hosts file, and _only_ if those site _only_ have links and included references (javascript sources, etc) which are _exactly_ listed in your hosts file.
Do me a favour - run wireshark on your PC, filter for port 53. See how often y
Re: (Score:2)
"...you even ADMIT I do get better security via my methods"
Umm, I didn't. I said quite specifically that your security is likely worse than just using DNS. But hey. If that's how you choose to configure your hosts, then that's great. Good luck to you.
I'll be out here in the badlands running with an empty hosts file, javascript switched on, frames enabled, cookies allowed, and Flash installed. Living the dream, baby.
Peace out, much love, etc.
Re: (Score:2)
"ACTUAL STORAGE CENTRAL POINT FOR THEM"
Again, there is _no_ central storage for in-addr.arpa. The reverse records are delegated just like the A records are. Do you honestly think the root servers hold every single PTR record on the public internet?
You know, for someone who makes a lot of noise about hosts files and DNS, I'd expect you to at least understand how DNS works.
Re: (Score:2)
None of that shows that you know anything about DNS. You're ranting into the abyss.
What have I done? Like you, noting of note. If we're waving our dicks about, though, I have a BSc in Computing Science, an RHCSA and an SCSA. I administer Unix, DNS and LDAP for a FTSE100 company.
And yet, here I am on Slashdot arguing with APK for some reason.
Re: (Score:2)
You read the wikipedia page! Good for you!
Yes, it is it's own TLD. It's also delegated out from the root nameservers, so there's still no central storage point and you're still vulnerable if you're relying on reverse lookups.
Re: (Score:2)
I'm at a loss here. You think when you do a reverse lookup you're only hitting the DNSSEC secured root servers? You really, genuinely don't understand how DNS works.
Well, it's been weird. I'm out. I hope your hosts file providers are never compromised, and your reverse lookups always return valid hostnames. Good luck. You'll need it.
Re: (Score:2)
1.
Using the hosts file is incredibly inefficient. Just role a DNS server, run it on localhost if you have to, and use that instead.
A hosts file needs 2 entries per domain. ie.
127.0.0.1 example.com
127.0.0.1 www.example.com
It then needs a new entry for every single subdomain.
127.0.0.1 ad100.example.com
127.0.0.1 ad200.example.com
127.0.0.1 ad300.example.com
2.
By setting up your malicious content to use random subdomains, like a4bacd4adef.domain.com renders any host files
Re: (Score:2)
I'm sorry but you fail to counter any points. Hosts file = inefficient and random subdomains CANNOT be countered by a hosts file.
As a spammer, I could setup a wildcard entry "* IN A " and just use simple PHP to set every image and every advert to use .domain.com. Hosts file cannot solve this. There is no argument here, this is FACT.
Your attempt to counter the localhost DNS server point by saying that the server itself would be compromised is a joke. You demonstrate complete misunderstanding of computer logi
Re: (Score:2)
Didn't realise "plain old text" reformatted tags.
Actual line #2:
As a spammer, I could setup a wildcard entry "* IN A [ip]" and just use simple PHP to set every image and every advert to use [random].domain.com. Hosts file cannot solve this. There is no argument here, this is FACT.
Re: (Score:2)
Yes more moving parts.
False. Still haven't found case to handle wildcards.
Citation needed.
Citation needed.
Data used for configuration != Data used in RAM during use.
OS ne
Re: (Score:2)
Okay I see you have no citations for those points, just guesswork. I accept this as you conceding the argument in my favor. That is acceptable.
Any operating system tricks to cache data are not exclusive to just a hosts file so any points made there are moot and disregarded.
Besides, the SPEED difference of any of these system would be unmeasurable (unless you have citations? oh you don't don't nevermind that then), its not what I am arguing. An internal DNS system (not affected by any sort of poisoning vulne
Re: (Score:2)
Please don't turn this into an e-peen competition. My kids are into that sort of thing. I have been writing software for over 35 years, so lets just put that to rest, it's immature.
Indexing vs "favourites at top" has no argument. Indexing was designed to speed up search, linear searching is the base at which indexing is compared to. Sure, for those at the top, its faster, for those at the bottom its slower, you can't predict the browsing habits of your users, so this sorting won't work. Overall, indexing is
Re: (Score:2)
I also don't care. I did a TLDR from "I shit on guys like you, everyday", not worth my time.
You're cracking at the seems with the rambling!
Right, back to the APK crap you keep going on about. You should place a notice on the software page that it requires an SSD in order to benefit.
Re: (Score:2)
So read-only file flag and NTFS ACLs. Nothing special then.
BTW I'm loving this discussion, I know you're a troll, and a good one, but its awesome to see how far people will go. Especially when you're also getting your link count up with each post :)
Re: (Score:2)
hosts file at %windir%/system32/drivers/etc/hosts
b026324c6904b2a9cb4b88d6d61c81d1.adverts.example.com 127.0.0.1
26ab0db90d72e28ad0ba1e22ee510510.adverts.example.com 127.0.0.1
6d7fce9fee471194aa8b5b6e47267f03.adverts.example.com 127.0.0.1
48a24b70a0b376535542b996af517398.adverts.example.com 127.0.0.1
1dcca23355272056f04fe8bf20edfce0.adverts.example.com 127.0.0.1
9ae0ea9e3c9c6e1b9b6252c8395efdc1.adverts.example.com 127.0.0.1
84bc3da1b3e33a18e8d5e1bdd7a18
Re: (Score:2)
This doesn't work. I can still access the site.
Please give me a working example of how to quickly and easily block ALL of microsoft.com in a single line.
DNS on localhost isn't compromisable. You are the very example of FUD. http://en.wikipedia.org/wiki/Fud [wikipedia.org]
Re: (Score:2)
I will now try with slashdot.org
Okay, it blocks it, great.
Oops, sorry. I remain unconvinced. I'll stick to an internal DNS server for blocking. Single point of con
Re: (Score:2)
Oh, you opened yourself up for being owned now :)
Any other process capable of writing to the hosts file is running as administrator. Therefore it kills your applications PID, and disables any service. The end.
Re: (Score:2)
Re: (Score:2)
Also, you are now slipping up on some important parts..
You just stated:
but then you argued that DNS is:
I can guarentee that an idle DNS server doesn't waste time checking
Re: (Score:2)
Did you miss the memo? "MS Security Essentials" is no longer trusted anti-virus software in the eyes of independent AV researchers. You look silly.
Notepad++ can edit hosts file and bypass the "MSSE protections", so um, yeah ... just, wow. Notepad++ must be awesome.
Re: (Score:2)
I have to leave the internets now :( I'm glad my afternoon appointment had been cancelled so I had the chance to make you sweat.
However at night I am a father and a husband and don't have time for these unimportant discussions.
Good day!
Re: (Score:1)
Hahahahhaa APK, what a surprise - here you are, regurgitating the same tired old rubbish.
Get this through your thick skull, nobody wants to read your shite about the fucking hosts file any more.
We've seen you spew this crap over and over and over and over again, don't you think it's time to give it a rest? Face it APK, you're a fifty-year-old man-child with an obsessive pattern of behaviour and a compulsion to make an annoyance of yourself that you should have gotten under control by your age.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Post your same non-arguments again - you're a retarded robot with the personality and reasoning skills of an escapee mental patient.
There ya go. I was wondering when you would come around to the conclusion that APK is an eliza-bot. A poorly (or brilliantly) coded one at that.
Re: (Score:2)
I can't fault you. It can be entertaining to engage with it. The biggest problem is when it gets broken and starts replying to EVERY post you make.
Re: (Score:2)
Oh Jebus, I think I must have enraged it. Sorry you got caught in the crossfire. :-(
Nah, I step in its line of fire every once in a while when I get bored.
Re: (Score:2)
P.S.=> GEORGE M. HOWELL (gmhowell) "thrives" on creating hassles for others & apparently do this ON PURPOSE? Please - grow up... apk
I won't grow up, [youtube.com]
(I won't grow up)
I don't want to go to school.
(I don't want to go to school)
Just to learn to be a parrot,
(Just to learn to be a parrot)
And recite a silly rule.
(And recite a silly rule)
If growing up means
It would be beneath my dignity to climb a tree,
I'll never grow up, never grow up, never grow up
Not me!
Not I,
Not me!
Not me!
I won't grow up,
(I won't grow up)
I don't want to wear a tie.
(I don't want to wear a tie)
And a serious expression
(And a serious expression)
In the middle of July.
(In the mi
Re: (Score:2)
Interesting, the chatbot APK can take observations about itself and attempt to turn them on others.
Re: (Score:1)
Re: (Score:2)
Sounds too much like a priest I knew as a child.
That's interesting; I'm starting to wonder if APK is explainable by an interaction with a priest HE may have had as a child.
Re: (Score:2)