Unexpected mail exchangers from nslookup

Question

I'm working on Windows 10 and I want, for example, to get the MX server of the site achab.it. Asking for nslookup -type=mx achab.it, I am expecting to obtain:

Server:  anyres1.fastwebnet.it
Address:  62.101.93.101

Non-authoritative answer:
achab.it        MX preference = 10, mail exchanger = mail.achab.it
achab.it        MX preference = 20, mail exchanger = mail2.achab.it

or something like that. Instead I get:

Server:  anyres1.fastwebnet.it
Address:  62.101.93.101

Non-authoritative answer:
achab.it.fastwebnet.it  MX preference = 10, mail exchanger = mx2.fastwebnet.it
achab.it.fastwebnet.it  MX preference = 10, mail exchanger = mx4.fastwebnet.it
achab.it.fastwebnet.it  MX preference = 10, mail exchanger = mx1.fastwebnet.it
achab.it.fastwebnet.it  MX preference = 10, mail exchanger = mx3.fastwebnet.it

where fastwebnet.it is my service provider.

Same problem with setting other servers, e.g. nslookup -type=mx achab.it 8.8.8.8.

I cannot see what's wrong. Isn't it the right way to get automatically the domain mail.achab.it starting from achab.it?

UPDATE: The output is the same even if I ask for nslookup -type=mx outlook.com or nslookup -type=mx fakesite.nodomain

Your service provider should expose DNS options to you somewhere. — mzhaase, Mar 02 '17 at 14:55
I don't know if I said that badly but achab.it is not a site of mine. The problem is client-side (see the update). — logi-kal, Mar 02 '17 at 15:00
Complain ***loudly*** to `fastwebnet.it` about them breaking DNS. In the meantime, you could try `nslookup -tmx achab.it.` (notice the `.` at the end) to see if that makes any difference. — user, Mar 02 '17 at 15:00
`nslookup -tmx achab.it.` returns `95.110.166.82` (i.e. `www.achab.it`). — logi-kal, Mar 02 '17 at 15:05

JFL · Accepted Answer · 2017-03-02T15:29:06.570

It is often forgotten that a DNS name end with a "."

To ease user life, many software accept the name without the ending dot and add it automatically.

Without it, the entered name is supposed to be relative.

Relative to what? To whatever DNS suffix is configured on the host.

Windows (as other OS do) actually manage several DNS suffixes. If you type "ipconfig /all" you'll find a Primary DNS suffix (that may be empty) and one or several Connection-specific DNS suffix There's also additional DNS search suffixes that can be configured.

You can control this in the advanced properties of TCP/IP in your network card properties:

When performing lookup for a relative name (that does not end with a dot) windows will try to resolve it with those suffixes.

It seems your modem receive the DNS suffix fastwebnet.it from your provider and this settings is transferred to your machine through DHCP.

score 1 · Answer 2 · answered Mar 02 '17 at 15:12

I think it's something in the way either your DNS client or your provider's DNS server is setup.

If the issue is replicated with the DNS server at 8.8.8.8, then I think your local resolver is appending a search domain it shouldn't be.

Looking at your output, the 'right' response is being returned: achab.it.fastwebnet.it is not the same as achab.it, and the first form's answer could well be correct (i.e. any MX request within fastwebnet.it will return this response).

In more technical terms, you are getting an answer for a relative domain name + your search domain.

So the first thing I would check is what the output of nslookup -type=mx achab.it. is (notice the ending .). That would make the request a fully qualified one, and should get your sanity back.

I am not sure how one goes about addressing this on Windows, I am afraid - on linux, this is something that would be fixed by adding options ndots:1 to resolv.conf (http://man7.org/linux/man-pages/man5/resolv.conf.5.html).

Unexpected mail exchangers from nslookup

2 Answers2