MX Record Query терпит неудачу
Вопрос
Я - парень из управляемого кода, поэтому, когда я взаимодействую с неуправляемым кодом, и он не работает, как рекламируется, я начинаю нервничать. Может кто-нибудь объяснить мне, почему это вернулось бы без записей MX, когда работает командная строка nslookup
?
[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)
}
Код ошибки, который возвращается, означает "не найдено записей для данного DNS-запроса"
Проблема в том, что это первый обнаруженный домен, который не прошел этот тест, но мне сказали, что это происходит "OFTEN". (пока никто не может определить для меня часто, но я над этим работаю)
В любом случае, когда я выполняю nslookup через командную строку, я возвращаюсь:
> 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)
Решение
Я не получаю никаких записей MX
для этого конкретного доменного имени, когда использую 'dig' отсюда.
Результаты 'nslookup', которые вы цитируете, взяты из записи SOA
домена и не содержат записей MX
. Запись SOA
возвращается в " полномочиях " раздел ответа DNS, даже если нет записей для конкретного заданного вами вопроса.
В отсутствие записей MX
агенты передачи почты (MTA) будут обрабатывать запись A
для хоста как запись MX
с приоритет 0 и попытайтесь установить SMTP-соединение с этим адресом.
См. раздел 5.1 в RFC 5321 . Обратите внимание, что хотя это совсем недавно RFC, такое поведение также существовало в предыдущих версиях спецификации SMTP.