If you launch nslookup and turn on debugging you'll see that Windows always tries to append its suffix first.
C:\>nslookup
Default Server: itads.example.com
Address: 0.0.0.0
> set debug=true
> www.yahoo.com
Server: itads.example.com
Address: 0.0.0.0
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
www.yahoo.com.example.com, type = A, class = IN
AUTHORITY RECORDS:
-> example.com
ttl = 3600 (1 hour)
primary name server = itads.example.com
responsible mail addr = itads.example.com
serial = 12532170
refresh = 1200 (20 mins)
retry = 600 (10 mins)
expire = 1209600 (14 days)
default TTL = 3600 (1 hour)
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 4, authority records = 0, additional = 0
QUESTIONS:
www.yahoo.com, type = A, class = IN
ANSWERS:
-> www.yahoo.com
canonical name = www.wa1.b.yahoo.com
ttl = 241 (4 mins 1 sec)
-> www.wa1.b.yahoo.com
canonical name = www-real.wa1.b.yahoo.com
ttl = 30 (30 secs)
-> www-real.wa1.b.yahoo.com
internet address = 209.131.36.158
ttl = 30 (30 secs)
-> www-real.wa1.b.yahoo.com
internet address = 209.191.93.52
ttl = 30 (30 secs)
------------
Non-authoritative answer:
Name: www-real.wa1.b.yahoo.com
Addresses: 209.131.36.158, 209.191.93.52
Aliases: www.yahoo.com, www.wa1.b.yahoo.com
As you can see above my machine tried to look for www.yahoo.com.example.com first, and the DNS server responded NXDOMAIN
(entry not found). You can confirm this by running nslookup www.yahoo.com.
(note the dot at the end of .com!) and you'll see that it is resolved normally.
What's happening is that your external DNS server is responding that they have an entry for "www.yahoo.com.example.com" and is returning your IP address for the root of your site. I'm not sure what service you use but I'm guessing that you have a wildcard mapping that tells your server to respond to any unknown query with a valid response, rather than returning NXDOMAIN
. You'll need to double check your settings for the server and confirm that it is only set to respond to queries for entries it actually has (example.com
, www.example.com
, mail.example.com
, etc.).
Remember that DNS works by checking the configured server and working its way up from there. The DNS query can take a path like the following pattern (of course this is just a example, it is probably wrong): Machine -> Local Router DNS (linksys) -> ISP DNS -> (2nd ISP DNS?) -> Root Server DNS -> TLD DNS -> Your External DNS server. Someone along that path is saying that www.yahoo.com.example.com
exists. Chances are it's your external DNS server.
EDIT
I figured I'd include one more tidbit about the randomness you mention. If this is really happening sporadically you may have a misconfigured external DNS server or their ISP could be providing a DNS hijacking service. Unfortunately I've seen more and more residential ISPs provide a "search service" for invalid domain names. Since almost all end users use their ISP DNS servers, the ISPs are now starting to redirect invalid domain entries to a search page - one usually laden with ads, irrelevant links and a small "Did you mean www.example.com?" with some results that may or may not be related to the domain name. I know that Verizon and Comcast are starting to do this, I believe Quest is starting to as well. Another possibility is OpenDNS, since they provide the same "search for a related domain" if it doesn't exist (it's their revenue after all).
My problem with suggesting that as the problem, though, is the fact that you say it's returning the address of your root record, which none of these would do if they were trying to search for it, they'd give you an IP of one of their web servers to handle the search.
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.
Best Answer
The
$env:userprofile\AppData\LocalLow\Sun\Java\Deployment\deployment.properties"
file has (presumably)ANSI
(orUTF-8
) encoding.On the other hand,
about_Redirection
help topic says:To redirect content to non-Unicode files, use the
Out-File
orAdd-Content
cmdlet with itsEncoding
parameter. For instance, something likeSee also
Add-Content
for FileSystem,Out-File
, andNote: you can query the
file.encoding
property orCharset.defaultCharset()
to find the current default encoding in Java.For the entire enterprise, you could configure above script to
Run Once
on user logon.