La query del record MX ha esito negativo
Domanda
Sono un tipo di codice gestito, quindi quando interagisco con un codice non gestito e non funziona come pubblicizzato, divento nervoso. Qualcuno può spiegarmi perché questo sarebbe tornato senza record MX, quando una riga di comando nslookup
funziona?
[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)
}
Il codice di errore che viene restituito significa "Nessun record trovato per una determinata query DNS"
Il calcio nei pantaloni è che questo è il primo dominio che ho trovato che non supera questo test, ma mi è stato detto che succede "spesso". (nessuno può ancora definire spesso per me, ma ci sto lavorando)
Comunque, quando eseguo un nslookup tramite il prompt dei comandi, torno indietro:
> 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)
Soluzione
Non ottengo alcun record MX
restituito per quel particolare nome di dominio quando utilizzo 'dig' da qui.
I risultati 'nslookup' che stai citando provengono dal record SOA
del dominio e non includono alcun record MX
. Il record SOA
viene restituito nell '"autorità" sezione della risposta DNS, anche se non ci sono record per la domanda specifica che hai posto.
In assenza di record MX
, gli agenti di trasferimento di posta (MTA) tratteranno il record A
per l'host come un record MX
con priorità 0 e prova invece a stabilire una connessione SMTP a quell'indirizzo.
Vedi la sezione 5.1 di RFC 5321 . Si noti che sebbene si tratti di un RFC molto recente, questo comportamento esisteva anche nelle versioni precedenti della specifica SMTP.