[dns-operations] need someone else to look at these servers

Emmanuel Thierry ml at sekil.fr
Tue Oct 14 23:18:53 UTC 2014


Le 15 oct. 2014 à 00:08, Lyle Giese a écrit :

> A customer is trying to send email to a customer that is using secureserver.net for email.
> Their MX record points to presmtp.ex3.secureserver.net.
> This is where things get screwy.
> Dig(+trace) shows that presemtp.ex3.secureserver.net has the following auth servers:
> gns1.secureserver.net
> gns2.secureserver.net
> gns3.secureserver.net
> However when I query these servers directly using dig, I get back No servers could be reached.
> (dig @gns1.secureserver.net presmtp.ex3.secureserver.net)
> When I use +notcp option, I get back:
> Warning: EDNS query returned status FORMERR - retry with '+noedns'.
> If I use +notcp and +noedns, it works and I get the A record.
> If I use +noedns, it works and I get the A record.
> Am I doing something wrong or are their servers/load balancers screwed up?  I know something is wrong, but would like someone with a bit more knowledge to look at this and give their opinion.

We can basically assume that their nameservers don't enable tcp, which is, as far as i know, a behaviour used by some administrators :

% nc -zv gns1.secureserver.net 53
nc: connect to gns1.secureserver.net port 53 (tcp) failed: Operation timed out
% nc -zv gns2.secureserver.net 53
nc: connect to gns2.secureserver.net port 53 (tcp) failed: Connection refused
% nc -zv gns3.secureserver.net 53
nc: connect to gns3.secureserver.net port 53 (tcp) failed: Operation timed out
% nc -zv -u gns1.secureserver.net 53
Connection to gns1.secureserver.net 53 port [udp/domain] succeeded!
% nc -zv -u gns2.secureserver.net 53
Connection to gns2.secureserver.net 53 port [udp/domain] succeeded!
% nc -zv -u gns3.secureserver.net 53
Connection to gns3.secureserver.net 53 port [udp/domain] succeeded!

However, the bad thing is that one server is actually dropping TCP packets instead of rejecting them (by the way, you may notice that gns1.secureserver.net and gns3.secureserver.net actually points to the same IP).
This behaviour might not help dns recursive servers to fallback to UDP when TCP failed.

Best regards
Emmanuel Thierry

More information about the dns-operations mailing list