ISPs Improve Their DNS Hijacking And How To Stop It
hackercodex.com
hackercodex.com
Interesting to note: no rDNS for either of those IP's.
Either way, the article provides a pretty interesting way around it, but I can't expect ISPs hell-bent on false lookup spoofing to sit on their hands for long enough to make this a practical long-term solution.
But for ISP's that insist on doing this, there are various workarounds besides the one mentioned in the blog post. It's quite easy. Tunneling inside HTTP is a last resort. At some point it's not worth the trouble for the ISP, e.g., to peek into every packet trying to stop users from getting a proper NXDOMAIN response.
OpenDNS already supports it:
It's the same as with DNSSEC. To get the full benefit, every point in the chain needs to be on board, from the source to the sink. If any link in the chain doesn't support it, you're SOL.
If you read Dempsky's announcement carefully, you notice the words "whenever possible". That could be almost never depending on DNSCurve uptake among DNS admins and users.
An easier solution is to just run your own instance of dnscache.
That's what OpenDNS uses.
[my head explodes] This is just begging to be hacked: bankofamerica can be mispelled a number of ways, and I doubt BoA has covered them all.
This is why it's amusing to watch trademark registrants going after domain names based on confusing variations of their registered mark.
Meanwhile their trademarks are being hijacked by DNS services and ISP's, in order to show ads, probably far more often (since these services and ISP's have huge user bases).
And for the trademark registrants, ISP's are much easier to locate and take action against than evasive domain name miscreants.
Pass the popcorn.
And that is, write your own resolver that only sends nonrecursive queries to authoritative nameservers.
If the DNS admin has configured DNS simply and sensibly, it will only take you 2 queries to get a name resolved. It's very fast.
If they are using Akamai or some other CDN, or they have a love for CNAMES and indirection, it can take many more queries. Sometimes up to 7.
net. => root (return tld)
example.net. => tld (return ns)
www.example.net. => ns (returns ns2)
www.example.net. => ns2
The tld server ip's are "hardcoded" into the resolver application and revised as needed from the root.zone.gz file periodically- these servers do not change very often. The application is just a simple lexer that can be easily edited and recompiled. Writing this thing was a learning experience: the vast majority of cases, DNS lookups follow some very predictable patterns.
So, to answer your question: that first lookup is unnecessary. There's no need to keep hitting the root to get a relatively small number of tld server ip's that rarely change or go inactive. It's easier just to download the root zone regularly to check for changes.
As for subdomains, such as www, that's the CNAME indirection to which I alluded. Everytime someone adds indirection, whatever their reasons (e.g. load balancing, CDN, etc.), it slows down the lookup process by necessitating more lookups. It's a small tradeoff that probably few people pay attention to.
From the resolver's perspective, it is more work and it does slow things down compared to the typical 2 query resolution.
Note I still say 2 queries because even with recursive resolvers like the ones we all use, the tld server ip's for the popular tld's are almost always already in the cache. You only need to lookup a single domain.com and the com tld server ip's will be there for all future queries.
So yes, you may only need to hit the root once to get the tld as it will be cached, but it is still a hit. I am not sure that downloading the root.zone.gz instead is necessarily required, especially with the amount of new tld's that they are planning on adding it would amount to a lot of wasted resources.
Also, for some domains (those in the UK are the ones that popped into my mind), you have sub-domains such as co.uk.
So that is another extra lookup... and depending on whether or not you want to use ANY or not in the lookup you find that if you query ns1.nic.uk for co.uk. (A) you get an SOA record back, but no NS results, so at that point instead of just being able to continue you'd have to retry with co.uk. (ANY). At that point you get back a truncated result, and need to retry over TCP...
Now you can continue on to ns1.nic.uk for co.uk. and ask it your question mydomain.co.uk. so and and so forth.
You've piqued my interest and I am thinking I may start keeping logs from my local recursive DNS resolver and start looking at what the cost is now versus what the cost would be if recursive DNS resolvers would go step by step themselves (keeping in mind TTL's and the like).
I don't want to successfully reach your bullshit ad host. I don't want to get successfully served an ad instead of timing out. I just want to fail.
Any other behavior is wrong.
I assume you ask this honestly.
The problem isn't something like "Oh, hey, well, there's some empty space so let's setup a lemonade stand until someone buys up the property." The address is supposed to be valid, or fail fast. It is of much greater utility to everyone (except the ad farmers) to fail fast.
No it isn't yours in an extreme minority edge case compared to most internet users. Users don't want a blank page with just a weird code on it.
They want links to click to get to the page that they meant to type in, or failing that a similar page link supplied by their ISP ...
This "average user"? Frankly, we've had the 'net for like fifteen years--now's a good a time for users to learn as any.
Unless, of course, you prefer to spoonfeed the next generation of consumer whores?
User make mistakes, domains are abandoned - for those cases this provides a simple service which reduces user effort.
Do I want to spoonfeed a generation of consumer whores? Would love to. But I suspect they like errant toddlers would spit out my message of anti-consumerism, sustainability, social action, fair trade ...
This page does not exist. Did you mean '...'?
Which most modern browsers give them provided their ISP does not hijack the NX response to present their ads.
Not doubting you, just wanted to add another data point.
If it isn't, oh well.
If it is, this is an exploit and is big news.
Talk about not drinking your own Kool-Aid...
In case it's not clear, even non-forwarding DNS servers have to make DNS queries to the authoritative servers of each domain.
It may stop invalid results for top level domains (queries to the root servers might not be intercepted), but would likely still serve ads for invalidsubdomain.validdomain.com.
This is one of many reasons why we need broad DNSSEC adoption.
"All records are signed offline. When a nameserver receives a query it looks up the answer plus the signature and returns the two (RRSIG + RRset) to the resolver. The signature is thus not created in real time. How can a secure-aware nameserver then respond to a query for something it does not know (that is, give an NXDOMAIN answer)? The only way to have offline signing and NXDOMAIN answers work together is to somehow sign the data you do not have.
In DNSSEC this is accomplished by the Next SECure (NSEC) record. This NSEC record holds information about the next record; it spans the nonexistence gaps in a zone, so to say."
Source: https://www.cisco.com/web/about/ac123/ac147/archived_issues/...
The namedroppers working group eventually conceded that, no, it wasn't OK to disclose every domain name signed under DNSSEC; that, for instance, virtually every large enterprise in the world had made a practice of setting up dual-facing DNS so that the world only saw a preapproved subset of their name.
And so we got the NSEC3 protocol, which uses a hashing scheme similar to Unix password files. So now, instead of directly dumping domains, attackers get to crack them. Daniel J. Bernstein has a couple presentations about how easy this is.
DNSSEC is a bit of a debacle.