Just wanting a second opinion. I was investigating why I and a fair few others were occasionally being redirected to eBay or seeing seemingly random sites when going to common places like Google, Twitter, etc. Turned out to be caused by the combination of a few things, one of which was the documented behaviour of the resolver library. Here's what happens:
1. OS boots up, DHCP sets the domain name to something.com.au. (ok) 2. Browser starts up, opens a lot of tabs, starts doing DNS lookups. 3. Because the ISPs DNS server is not 100% reliable, some site name lookups do not get a DNS response within the timeout (first problem, but nothing to do with the OS). 4. Because the resolver library didn't resolve "google.com.au" or " twitter.com" it does a search. If there's no explicit DNS search path set then RES_DNSRCH is activated and it looks up "google.com.au.something.com.au" (ok -- just appending the domain name). Of course, that doesn't exist so it gets "no such domain". 5. So the resolver library "walks back up" the domain name and next tries to resolve "google.com.au.com.au" (second problem -- I don't think the resolver library should be going back that far it but it's obviously been like that for a very long time and is documented). 6. Some smart alec actually owns "au.com.au" and "com.com.au" and they've configured DNS entries for "google.com.au.com.au" and a host of other sites (third problem). It's not a wildcard match. " nosuchdomain.blah.blah.blah.au.com.au" returns "no such domain." It's really quite a head-trip to type "google.com.au" and get "Welcome to ASZ.COm.AU" or get redirected to eBay. I thought it was a DNS cache poisoning attack at first but it isn't. I think it's a relatively minor issue because all 3 conditions must be met and the owner of au.com.au and com.com.au (same entity) don't seem to be doing anything malicious with it (yet). But a quick Google shows a surprising number of people fruitlessly searching for trojans and viruses because they're affected. The designer/implentor of the resolver library knew not to walk all the way back to ".com" if your domain was "something.com". So the problem only affects people whose country domains include sub-domains. But I think for the same reason you shouldn't walk all he way back to ".com" it shouldn't walk all the way back to ".com.au". Just IMHO. Odd thing is -- OpenBSD doesn't seem to be vulnerable out of the box. That's because dhcp-client writes /etc/resolv.conf and includes a search domain. If you have search domains then RES_DNSRCH doesn't happen. To reproduce the issue, remove the "search" option from /etc/resolv.conf then "ping bom.gov.au" (you'll need a "domain" option set in /etc/resolv.conf like " optusnet.com.au"). You can reliably reproduce the behaviour with bom.gov.aubecause they haven't configured A records for just " bom.gov.au" so the RES_DNSRCH feature is triggered in the absence of a search directive. So does OpenBSD write a seach domain to /etc/resolv.conf because this issue was already known? Although the DHCP standard allows it my DHCP server is definitely not setting a search path. OSX, Windows and Linux don't do this and the problem is easily reproducible. Haven't checked the other *BSDs. Maybe I'm being too paranoid (but then, that's why I use OpenBSD... :-) ). Dan
