Different DNS query results from different locations

It all looks perfrectly normal to me. The name servers for iis.se are ns.nic.se, ns2.nic.se, and ns3.nic.se.

You get the Server Unknown message because you don't have a PTR zone set up on your DNS servers for your subnet (which isn't required). When you run nslookup from the DNS server the DNS client on the server (which is what nslookup uses, as the DNS server is also a DNS client and operates as any other DNS client does) first performs a PTR lookup to find the name of the server configured in the DNS settings of the TCP\IP protocol bound to the NIC. Not finding a PTR record, nslookup responds with Server Unknown. This is perfectly normal and acceptable.

Next you issue the query for www.iis.se and get a response from one of the name servers at iis.se from both the IPv6 and IPv4 addresses of that name server, that it can't find a record for www.iis.se. This is a perfectly normal response if no record for www exists.

You do that two more times against two different name servers and get the same response, which again is perfectly normal where no record for www.iis.se can be found.

You do that a third time on a server that has 127.0.0.1 configured as it's DNS server in the TCP\IP protocol settings of the NIC and get a request timed out, which tells me that the DNS client is pointing to 127.0.0.1 for DNS but that the DNS server (if you're running this particular nslookup from the DNS server) isn't listening on 127.0.0.1 so the query times out.

Try running nslookup against each of the name servers for the iis.se domain and query each one for www and see what they answer.

This is NXDOMAIN hijacking, revealing to you a harmless aspect of how DNS search suffixes work.

I'm going to guess that your DNS resolution is to a local device, which contains copies of your zones, then does recursive lookups for other zones off of an internet server (which is doing NXDOMAIN hijacking).

A client with a DNS search suffix will issue additional queries with the chunks of the suffix appended. If my system has a suffix list of, for instance, foo.domain.com then domain.com, and I do a lookup against a single-name host server, it'll execute the following queries, in order, until it finds something:

server.
server.foo.domain.com.
server.domain.com.

(the . at the end is to specify, in DNS terms, that it's relative to the root and nothing else)

Which is great, and makes perfect sense. If server doesn't exist at server., it'll be looked for at server.foo.domain.com. - if it doesn't exist, it keeps going; if it finds an answer, it'll stop.

Where it starts to look a little less normal is when you search for something that you're thinking is the FQDN - but DNS doesn't know that (unless you're doing an nslookup with the . at the end). So, if I search for server2.domain.com, it'll search like this:

server2.domain.com.
server2.domain.com.foo.domain.com.
server2.domain.com.domain.com.

Those last 2 make very little sense to you and me, but the resolver doesn't know any better, and needs to check.

Which brings us to what you're seeing. Your search suffix list probably looks something like this:

domain.parentdomain1.parentdomain2.net
parentdomain1.parentdomain2.net
parentdomain2.net

And, your recursive DNS servers probably contain a zone for parentdomain1.parentdomain2.net, but not for parentdomain2.net.

So, the query happens like this:

hostname.domain.parentdomain1.parentdomain2.net.

(NXDOMAIN response - you'll want to look into why that is happening if this is where this record is supposed to be)

hostname.domain.parentdomain1.parentdomain2.net.domain.parentdomain1.parentdomain2.net.

(Your name server likely has a zone for parentdomain1.parentdomain2.net, and throws another NXDOMAIN)

hostname.domain.parentdomain1.parentdomain2.net.parentdomain1.parentdomain2.net.

(same result as previous)

hostname.domain.parentdomain1.parentdomain2.net.parentdomain2.net.

(Now, your DNS server forwards the query to your upstream forwarders for lack of an authoritative zone. Your upstreams dutifully send back a false response, in a misguided attempt at getting some extra advertising revenue)

So! This is likely a simple issue with a record, which got a lot more confusion because of abusive practices by your ISP or whoever else runs that upstream DNS server. There's a lot of variables that I've made assumptions on above, but do some checking on how things are resolving for specific queries (with . on the end to eliminate the search suffix) and it should track pretty closely with how I've outlined it.