Question

I’m a managed code guy, so when I interop with unmanaged code, and it doesn’t work as advertised, I get twitchy. Can someone explain to me why this would come back with no MX records, when a command line nslookup works?

[DllImport('dnsapi', EntryPoint = 'DnsQuery_W', CharSet = CharSet.Unicode, SetLastError = true, ExactSpelling = true)] private static extern int DnsQuery([MarshalAs(UnmanagedType.VBByRefStr)]ref string pszName, QueryTypes wType, QueryOptions options, int aipServers, ref IntPtr ppQueryResults, int pReserved);  string domain = 'HomeTechnologySolutions.com'; int num1 = DnsQuery(ref domain, QueryTypes.DNS_TYPE_MX, QueryOptions.DNS_QUERY_BYPASS_CACHE, 0, ref ptr1, 0); if (num1 != 0) {     throw new Win32Exception(num1) } 

The error code that comes back means ‘No records found for given DNS query’

The kick in the pants is that this is the first domain I have found that fails this test, but I am told it happens ‘OFTEN’. ( no one can define often for me yet, but I am working on that)

Anyway, when I perform a nslookup through the command prompt, I get back:

> set type=mx > hometechnologysolutions.com Server:  dhcp.removedtoprotectedtheguilty.com Address:  10.0.0.9  hometechnologysolutions.com         primary name server = ns1.streetsimple.com         responsible mail addr = hostmaster.streetsimple.com         serial  = 11         refresh = 900 (15 mins)         retry   = 600 (10 mins)         expire  = 86400 (1 day)         default TTL = 3600 (1 hour) 

Answer 1

I don’t get any MX records returned for that particular domain name when using ‘dig’ from here either.

The ‘nslookup’ results that you’re quoting there are from the domain’s SOA record and don’t include any MX records. The SOA record is returned in the ‘authority’ section of the DNS response, even if there’s no records for the specific question you asked.

In the absence of MX records, mail transfer agents (MTAs) will treat the A record for the host as an MX record with priority 0 and attempt to make an SMTP connection to that address instead.

See section 5.1 of RFC 5321. Note that although this is a very recent RFC, this behaviour also existed in previous versions of the SMTP specification.