Em 06-12-2013 14:31, Chris Smith escreveu:
> This falls under the category "When in doubt, ask the OpenBSD guys"
> (and as all of my firewalls are running OpenBSD I hope this isn't too
> off topic).
>
> Basically, four of my networks are not getting an answer for a
> specific mx query from dyn.com's DNS server. Yet every other DNS cache
> I've queried works just fine (Google, Level3, Hurricane Electric,
> Comcast, etc.) and dyn's support claims there is no problem on their
> end and all of their tests return the proper answer just as one of my
> networks does.
>
> Results from the four non-working networks (two are on Comcast, one is AT&T):
> =========================================
> dig @216.146.35.35 lwtitle.com mx
>
> ; <<>> DiG 9.4.2-P2 <<>> @216.146.35.35 lwtitle.com mx
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5502
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;lwtitle.com. IN MX
>
> ;; Query time: 29 msec
> ;; SERVER: 216.146.35.35#53(216.146.35.35)
> ;; WHEN: Fri Dec 6 11:18:05 2013
> ;; MSG SIZE rcvd: 29
> =========================================
> Consequently mail fails to get sent to the lwtitle.com domain.
>
> I should note that if I dig with +trace the proper answer does show up:
> =========================================
> dig @216.146.35.35 lwtitle.com mx +trace
>
> ; <<>> DiG 9.4.2-P2 <<>> @216.146.35.35 lwtitle.com mx +trace
> ; (1 server found)
> ;; global options: printcmd
> . 518400 IN NS a.root-servers.net.
> . 518400 IN NS b.root-servers.net.
> . 518400 IN NS c.root-servers.net.
> . 518400 IN NS d.root-servers.net.
> . 518400 IN NS e.root-servers.net.
> . 518400 IN NS f.root-servers.net.
> . 518400 IN NS g.root-servers.net.
> . 518400 IN NS h.root-servers.net.
> . 518400 IN NS i.root-servers.net.
> . 518400 IN NS j.root-servers.net.
> . 518400 IN NS k.root-servers.net.
> . 518400 IN NS l.root-servers.net.
> . 518400 IN NS m.root-servers.net.
> ;; Received 228 bytes from 216.146.35.35#53(216.146.35.35) in 34 ms
>
> com. 172800 IN NS j.gtld-servers.net.
> com. 172800 IN NS k.gtld-servers.net.
> com. 172800 IN NS h.gtld-servers.net.
> com. 172800 IN NS b.gtld-servers.net.
> com. 172800 IN NS c.gtld-servers.net.
> com. 172800 IN NS e.gtld-servers.net.
> com. 172800 IN NS i.gtld-servers.net.
> com. 172800 IN NS l.gtld-servers.net.
> com. 172800 IN NS m.gtld-servers.net.
> com. 172800 IN NS a.gtld-servers.net.
> com. 172800 IN NS f.gtld-servers.net.
> com. 172800 IN NS d.gtld-servers.net.
> com. 172800 IN NS g.gtld-servers.net.
> ;; Received 489 bytes from 202.12.27.33#53(m.root-servers.net) in 116 ms
>
> lwtitle.com. 172800 IN NS ns21.domaincontrol.com.
> lwtitle.com. 172800 IN NS ns22.domaincontrol.com.
> ;; Received 113 bytes from 192.12.94.30#53(e.gtld-servers.net) in 115 ms
>
> lwtitle.com. 3600 IN MX 0
> lwtitle-com.mail.protection.outlook.com.
> lwtitle.com. 3600 IN NS ns22.domaincontrol.com.
> lwtitle.com. 3600 IN NS ns21.domaincontrol.com.
> ;; Received 133 bytes from 208.109.255.11#53(ns22.domaincontrol.com) in 32 ms
> =========================================
> Although this doesn't help normal resolution.
>
> So I'm baffled. Any clues?
>
> Thanks,
>
> Chris
>
Chris,
I do not know if it is the case, but many isp's today use dns
transparent proxying. That is, even if you're not using their provided
dns servers, they intercept your dns connection, and they do all sort of
nasty things with it, ranging from displaying ad pages for mistyped
domains, to recording every dns query you make.
You can try using the site www.dnsleaktest.com to see if it is your
case. If it is, I suggest you to use the dnscrypt proxy, which is a
implementation of dnscurve, that was made by opendns. By default it uses
the opendns server, but there are others servers enabled for it and you
can use one of your servers too. Try this and see if it improves your
situation.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
