Can nslookup be made to agree with wget ?

[Skunk Worx]

Have you looked at what's in the html file you get returned? Maybe it's some kind of ISP redirect message.

My wget command fails :

$ wget fedoraf.org
--2009-12-29 19:44:32--  http://fedoraf.org/
Resolving fedoraf.org... failed: Name or service not known.
wget: unable to resolve host address “fedoraf.org”

Dig reverse shows :

$ dig -x 208.73.210.27
...
;; ANSWER SECTION:
27.210.73.208.in-addr.arpa. 305	IN	PTR	parkinglot.information.com.

You could also compare strace for the two commands to see what config files they are opening. Dig and nslookup only use /etc/resolv.conf while wget attempts to resolve using /etc/nsswitch.conf and /etc/hosts, etc. Probably something related to one of those files.

$ strace  wget fedoraf.org 2>&1 | grep open | grep '/etc' 
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/etc/wgetrc", O_RDONLY)           = 3
open("/etc/localtime", O_RDONLY)        = 3
open("/etc/nsswitch.conf", O_RDONLY)    = 3
open("/etc/host.conf", O_RDONLY)        = 3
open("/etc/resolv.conf", O_RDONLY)      = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3

$ strace dig fedoraf.org  2>&1 | grep open | grep '/etc'
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/etc/pki/tls/openssl.cnf", O_RDONLY) = 6
open("/etc/resolv.conf", O_RDONLY)      = 6

---------- Post added at 08:46 PM CST ---------- Previous post was at 08:05 PM CST ----------

BTW if you are just looking for a way to convert a host name to an ip address that uses all the local config files (including dns) I've used 'ping -w1 -c1 host' but this can take a second to exit if there is no reply.

[tashirosgt]

Using strace is a good idea!

Compared to yours, my strace of wget opens an additional file, /etc/selinux/config.

My first reading of the files like /etc/nsswitch.conf shows nothing that would cause a difference - not that I claim to completely understand that file yet.

The page that I get back is an advertising page (complained about in another thread by me in the Security section of the forum). But I'm not sure if that's what you mean by an "ISP redirect". My focus now is on where the 208.73.210.27 comes from. My understanding of the wget results is that the page I get back comes from that IP. Does "ISP redirect" refer to the 208.73.210.27?

---Edit: As you said, a "ping -w1 -c1 fedoraf.org" returns an answer from the same IP as wget.

[madmix]

tashirosgt,

Do you have any entry for fedoraf.org in your /etc/host file? And what happens when you ping/wget any other unregistered domain like fedorag.org, for example?

An URL redirection doesn't explain why you don't have results from nslookup/dig. At most it could explain why you had different IP address from what you get with ping/wget. Besides, your output from wget shows no redirection message.

[tashirosgt]

My results:

[sgt@autry ~]$ cat /etc/host
cat: /etc/host: No such file or directory

[sgt@autry ~]$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

[sgt@autry ~]$ ping fedorag.org
PING fedorag.org.myhouse.org (208.73.210.27) 56(84) bytes of data.
64 bytes from parkinglot.information.com (208.73.210.27): icmp_seq=1 ttl=245 time=89.6 ms

[sgt@autry ~]$ nslookup fedorag.org
Server: 216.223.224.6
Address: 216.223.224.6#53

** server can't find fedorag.org: NXDOMAIN

[sgt@autry ~]$ dig fedorag.org

; <<>> DiG 9.6.1-P1-RedHat-9.6.1-6.P1.fc11 <<>> fedorag.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50642
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;fedorag.org. IN A

;; AUTHORITY SECTION:
org. 597 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2008954426 1800 900 604800 86400

;; Query time: 60 msec
;; SERVER: 216.223.224.6#53(216.223.224.6)
;; WHEN: Wed Dec 30 09:01:43 2009
;; MSG SIZE rcvd: 92

[Skunk Worx]

I think if you strace the 'ping -c1 -w1 fedorag.org' command like this :

$ strace -o /tmp/foo.txt ping -w1 -c1 fedorag.org

...and view the tmp file, then search for the first "connect" call with the IP address 208. in it, you will see an "open" of a file several lines above the 'connect' call. This file is the culprit.

---
John

[tashirosgt]

file /tmp/foo.txt

execve("/bin/ping", ["ping", "-w1", "-c1", "fedorag.org"], [/* 26 vars */]) = 0
brk(0) = 0x1135000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb419a19000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb419a18000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=104595, ...}) = 0
mmap(NULL, 104595, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb4199fe000
close(3) = 0
open("/lib64/libidn.so.11", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\36 0.\340\242;\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=208848, ...}) = 0
mmap(0x3ba2e00000, 2301640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3ba2e00000
mprotect(0x3ba2e31000, 2097152, PROT_NONE) = 0
mmap(0x3ba3031000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x31000) = 0x3ba3031000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\3 53\341\227;\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1825624, ...}) = 0
mmap(0x3b97e00000, 3594344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3b97e00000
mprotect(0x3b97f64000, 2097152, PROT_NONE) = 0
mmap(0x3b98164000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x164000) = 0x3b98164000
mmap(0x3b98169000, 18536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3b98169000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb4199fd000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb4199fc000
arch_prctl(ARCH_SET_FS, 0x7fb4199fc6f0) = 0
mprotect(0x3b98164000, 16384, PROT_READ) = 0
mprotect(0x3b97c1e000, 4096, PROT_READ) = 0
munmap(0x7fb4199fe000, 104595) = 0
brk(0) = 0x1135000
brk(0x1156000) = 0x1156000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=84748752, ...}) = 0
mmap(NULL, 84748752, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb414929000
close(3) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
getuid() = 0
setuid(0) = 0
getpid() = 6232
open("/etc/resolv.conf", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=81, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb419a17000
read(4, "; generated by /sbin/dhclient-sc"..., 4096) = 81
read(4, "", 4096) = 0
close(4) = 0
munmap(0x7fb419a17000, 4096) = 0
uname({sys="Linux", node="autry.myhouse.org", ...}) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(4) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(4) = 0
open("/etc/nsswitch.conf", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=1696, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb419a17000
read(4, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1696
read(4, "", 4096) = 0
close(4) = 0
munmap(0x7fb419a17000, 4096) = 0
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=104595, ...}) = 0
mmap(NULL, 104595, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7fb4199fe000
close(4) = 0
open("/lib64/libnss_files.so.2", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`!\ 0\0\0\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=62808, ...}) = 0
mmap(NULL, 2147728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fb41471c000
mprotect(0x7fb414728000, 2093056, PROT_NONE) = 0
mmap(0x7fb414927000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0xb000) = 0x7fb414927000
close(4) = 0
mprotect(0x7fb414927000, 4096, PROT_READ) = 0
munmap(0x7fb4199fe000, 104595) = 0
open("/etc/host.conf", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=26, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb419a17000
read(4, "multi on\norder hosts,bind\n", 4096) = 26
read(4, "", 4096) = 0
close(4) = 0
munmap(0x7fb419a17000, 4096) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 4
fcntl(4, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fstat(4, {st_mode=S_IFREG|0644, st_size=158, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb419a17000
read(4, "127.0.0.1 localhost localhost."..., 4096) = 158
read(4, "", 4096) = 0
close(4) = 0
munmap(0x7fb419a17000, 4096) = 0
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=104595, ...}) = 0
mmap(NULL, 104595, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7fb4199fe000
close(4) = 0
open("/lib64/libnss_dns.so.2", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\ 20\0\0\0\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=27736, ...}) = 0
mmap(NULL, 2117880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fb414516000
mprotect(0x7fb41451b000, 2093056, PROT_NONE) = 0
mmap(0x7fb41471a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x4000) = 0x7fb41471a000
close(4) = 0
open("/lib64/libresolv.so.2", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\02 09\240\242;\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=111144, ...}) = 0
mmap(0x3ba2a00000, 2198152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x3ba2a00000
mprotect(0x3ba2a15000, 2097152, PROT_NONE) = 0
mmap(0x3ba2c15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x15000) = 0x3ba2c15000
mmap(0x3ba2c17000, 6792, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3ba2c17000
close(4) = 0
mprotect(0x3ba2c15000, 4096, PROT_READ) = 0
mprotect(0x7fb41471a000, 4096, PROT_READ) = 0
munmap(0x7fb4199fe000, 104595) = 0
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("216.223.224.6")}, 28) = 0
gettimeofday({1262223179, 767628}, NULL) = 0
poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "P\224\1\0\0\1\0\0\0\0\0\0\7fedorag\3org\0\0\1\0\1 ", 29, MSG_NOSIGNAL, NULL, 0) = 29
poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [95]) = 0
recvfrom(4, "P\224\201\203\0\1\0\0\0\1\0\0\7fedorag\3org\0\0\1 \0\1\3or"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("216.223.224.6")}, [16]) = 95
close(4) = 0
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("216.223.224.6")}, 28) = 0
gettimeofday({1262223179, 878608}, NULL) = 0
poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "2D\1\0\0\1\0\0\0\0\0\0\7fedorag\3org\7myhouse"... , 41, MSG_NOSIGNAL, NULL, 0) = 41
poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}])
ioctl(4, FIONREAD, [165]) = 0
recvfrom(4, "2D\201\200\0\1\0\1\0\2\0\2\7fedorag\3org\7myhouse "..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("216.223.224.6")}, [16]) = 165
close(4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("208.73.210.27")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(57919), sin_addr=inet_addr("10.0.0.5")}, [16]) = 0
close(4) = 0
setsockopt(3, SOL_RAW, ICMP_FILTER, ~(ICMP_ECHOREPLY|ICMP_DEST_UNREACH|ICMP_SOURCE_QUE NCH|ICMP_REDIRECT|ICMP_TIME_EXCEEDED|ICMP_PARAMETE RPROB), 4) = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
....snip

What does the option "ICMP_REDIRECT" do in setsockopt ?

[Skunk Worx]

You can google for that ICMP option....I think it has no bearing on the problem as the address is already discovered at that time.

What happens if you repeat the strace test above with networking disabled or unplugged? Do you still see the 'connect' attempt to the evil 208.* IP? If you don't see it, the implication is it's coming from outside the machine.

Do you have any other machines on the network and do they have the problem too?

I see from your older thread you booted a liveDVD and the problem stopped. This implies it's stored on the hard drive as configuration somewhere.

Consider booting from the liveDVD again and checking the contents of /etc/resolv.conf. /etc/host.conf, /etc/nsswitch.conf and compare them to being booted from the hard drive.

What if you bypass your router and plug the machine directly into the DSL modem (or whatever)? If it goes away, your router might be ginked up somehow.

Sorry for asking so much at once but I figured it would save time since you've been fighting it for a few days now.

[tashirosgt]

With the phone line unplugged, I don't see the 208.73.210.27 address anywhere in the strace.

My equipment is a DSL Modem/Router combination. I don't have a network setup as such. I plug various machines into the ports of the router, but I haven't gotten around to trying to communicate from machine to machine. I merely communicate between a machine and the internet. Usually only one machine is turned on at a time.

Machines that get redirected to the 208 address are a FC 11 64 bit system and a FC 12 64 bit system.

( If booted from the FC 11 live CD, neither of the above machines gets redirected.)

Machines that do not get redirected are an Ubuntu 9.10 system and a FC 8 32 bit system.

(I notice my 32 bit systems work faster on the internet that my FC 64 bit systems!)

You are correct that I should make a detailed comparison of files like /etc/nsswitch.conf on pairs of machines. I will do that.

[stevea]

Wow - talk about doing things the hard way. Strace is the wrong tool for this job.

The two tools you need a wireshark and ltrace. Possibly gdb but that's a hard path.
~ICMP_REDIRECT is not related to your issue, it's used when your system is not routing.

Step one - use wireshark and capture the packets for both commands. Each will start with DNS requests and acknowledge and likely that will show where he addresses are coming from. Carefully examine the dns requests looking for differences, There is still a responable chance you are seeing some protocol re-direct but also most probably you are seeing different DNS request params.

[Skunk Worx]

Wow - talk about doing things the hard way. Strace is the wrong tool for this job.

Everyone has an opinion, I guess. If you take a look at both this and the previous thread (he's been battling this for days) there are many hints it's not DNS at all, but a local configuration file on the hard drive.

[leigh123linux]

Threads merged.

[tashirosgt]

I used "ltrace ping fedoraf.org" on my FC11 machine and on my Ubuntu 9.10 machine.

The significant difference is that on the FC11 machine, the string: "fedoraf.org.myhouse.org" is created.

"ping fedoraf.org" on the FC 11 finds an IP for the adversing site.

"ping fedoraf.org" on the Ubuntu machine does not. However if I do "ping fedoraf.org.myhouse.org" , it does find the IP for the advertising site.

I know that "myhouse.org" is a name that I used somewhere is setting up the network when I installed Fedora Core 11 (since it is the example name often used in Linux documentation and it seems arbitrary.).

The file that implements this name is probably /etc/sysconfig/network which has the line:
HOSTNAME=autry.myhouse.org

The name myhouse.org is also in other places like /etc/cups/printers.conf, so it may be a pain in the neck to change it.

How's this for a theory?:

Perhaps the searchportal.information people occupy some domains with common "default" names like "myhouse.org" and perhaps some with "foo" in them.

The behavior of ping,wget,traceroute and similar commands is to search first for the given name. If no IP for it is found by the DNS server, then they try appending the local domain name to the given name and search again. Apparently nslookup and dig do not do this.

On the Ubuntu machine, I didn't provide a name for my network. I don't remember if the installation asked me for one.

[madmix]

You're on the right track about the domain "myhouse.org". It's being appended to your queries as you first showed here:

[sgt@autry ~]$ ping fedorag.org
PING fedorag.org.myhouse.org (208.73.210.27) 56(84) bytes of data.
64 bytes from parkinglot.information.com (208.73.210.27): icmp_seq=1 ttl=245 time=89.6 ms

Since your HOSTNAME=autry.myhouse.org in /etc/sysconfig/network, your domain is myhouse.org. Now the reason why you get different answers from ping/wget and from dig/nslookup is because the first use the function gethostbyname(3) while the latter don't. Dig/nslookup use their own libraries. This is what I get when I set my domain to myhouse.org:

$ ltrace ping -c1 fedoraf.org 2>&1 | grep fedora
inet_aton("fedoraf.org", 0x80629e4)              = 0
gethostbyname("fedoraf.org")                     = 0x54bda4
strncpy(0xbfe52f44, "fedoraf.org.myhouse.org", 63) = 0xbfe52f44

$ ltrace dig fedoraf.org 2>&1 | grep fedora
strlen("fedoraf.org")                            = 11
strncpy(0x90a7f84, "fedoraf.org", 1024)          = 0x90a7f84

gethostbyname(3) says that "the current domain and its parents are searched unless name ends in a dot". On the other hand this is not how dig/nslookup operate. This is why it's being appended in the ping/wget results. If you add a trailling dot and try to ping fedora.org. your results will be the same between ping and dig.

Despite of what you said, the domain myhouse.org is not arbitrary but it is registered already. So if you insist on this name you'll behave as if you were part of this domain. I suggest you change it unless you find some configuration that is acceptable to you.

$ whois myhouse.org
...
Domain ID:D105041070-LROR
Domain Name:MYHOUSE.ORG
Created On:23-Oct-2004 18:51:28 UTC
Last Updated On:29-Sep-2008 17:12:45 UTC
Expiration Date:23-Oct-2010 18:51:28 UTC
Sponsoring Registrar:Dotster, Inc. (R34-LROR)
Status:OK
Registrant ID:DOT-M5OIFHRES4HK
Registrant Name:Marco Ferro
Registrant Street1:Box 749
Registrant Street2:
Registrant Street3:
Registrant City:Fribourg
Registrant State/Province:CH
Registrant Phone:+41.413546798
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:marcoferro@privacymail.com
...

$ dig myhouse.org
...
myhouse.org.		7105	IN	A	208.73.210.27
...

$ dig -x 208.73.210.27
...
27.210.73.208.in-addr.arpa. 600	IN	PTR	parkinglot.information.com.
...

Now the interesting part is that the direct and reverse addresses don't match. So who owns the domain parkinglot.information.com?

$ whois information.com
...
Domain Name:                 information.com
Registrant
------------------------------------------------------------
Name:                        Host Master
Organization:                Oversee.net
Email:                       hostmaster@oversee.net
Address:                     515 S. Flower Street, Suite 4400
City, Province, Post Code:   Los Angeles, California, 90071
Country:                     US
...

If you go to the Oversee.net website you will understand where your unsolicited ads come from. I pasted an excerpt here:

Monetizing Direct Navigation Traffic

[...] In addition, there are a significant number of users who type in generic, or descriptive domain names not knowing whether a website actually exists. [...]

[...] Its DomainSponsor business unit offers sophisticated monetization technology to domain owners who have undeveloped domains either because they intend to sell them at some point, or because they have not yet executed a website development plan. [...]

The owner generates monthly cash flow from the ad clicks. And the advertiser receives traffic with high conversion rates by virtue of the fact that these users had very specific content needs and motivations in mind when they started the direct navigation process.

Hope that helps.