[bdNOG] Yahoo Mail can't communicate with my domain servers

Brian Candler brian at nsrc.org
Thu Dec 24 02:16:56 BDT 2015


On 23/12/2015 19:44, Anurag Bhatia wrote:
> I don't have routing issues with those IPs. ICMP is working perfactly 
> fine and hence server is reachable.
>
> anurag at server7:~$ ping -c 5 103.9.185.229
> PING 103.9.185.229 (103.9.185.229) 56(84) bytes of data.
> 64 bytes from 103.9.185.229 <http://103.9.185.229>: icmp_seq=1 ttl=55 
> time=209 ms
> 64 bytes from 103.9.185.229 <http://103.9.185.229>: icmp_seq=2 ttl=55 
> time=209 ms
> 64 bytes from 103.9.185.229 <http://103.9.185.229>: icmp_seq=3 ttl=55 
> time=209 ms
> 64 bytes from 103.9.185.229 <http://103.9.185.229>: icmp_seq=4 ttl=55 
> time=209 ms
> 64 bytes from 103.9.185.229 <http://103.9.185.229>: icmp_seq=5 ttl=55 
> time=209 ms
>
> --- 103.9.185.229 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4007ms
> rtt min/avg/max/mdev = 209.578/209.646/209.734/0.056 ms
>
But you're saying you can't get DNS responses when querying from 
server7, right?

# on server7
dig @183.9.185.229 btraccl.net mx
# no reply?

OK, then unless someone is spoofing ICMP echo, then either:
* there is some filtering going on somewhere
* your nameserver isn't answering queries from certain addresses 
(unlikely but possible).

I suggest running tcpdump on your nameserver as suggested before:

tcpdump -i eth0 -nn -s0 -v host <server7 IP>

and repeat the query from server7. This will demonstrate whether the 
filtering is of the inbound packets. Incidentally, try also the ping 
from server7 and check this tcpdump sees the inbound icmp echo requests 
and outbound icmp echo replies. (It's not entirely impossible that some 
firewall somewhere is spoofing the icmp)

So the scenarios you might have are:
- no packet arrives
- the packet arrives, but no response is sent
- the packet arrives and response is sent (but the response doesn't 
reach the client)

If udp port 53 packets aren't arriving at the server, then they are 
being filtered somewhere. Certainly some ISPs do filter UDP port 53 
and/or UDP port 123; this is because their customers have been known to 
participate in DNS reflection and/or NTP reflection attacks. If you can 
prove your ISP is doing this, then they can fix it for you. If it only 
happens to certain parts of the Internet then it could be the filtering 
is taking place on one of their upstreams but not the other. (*)

If you have root on server7, then try this:

# in one window
sudo tcpdump -i eth0 -nn -s0 -v host 103.9.185.229 or icmp
# in another window
dig @103.9.185.229 btraccl.net mx

If you are lucky, you may see an "ICMP Admin Prohibited" message coming 
back from somewhere. If you do, the source address of this packet will 
tell you which router is blocking the packet.

Regards,

Brian.

(*) Looking on route-views.oregon-ix.net, I see that AS58616 appears to 
have two upstreams: AS58587 and AS132602. That agrees with this:
http://bgp.he.net/AS58616#_graph4

Traceroutes from affected and unaffected parts of the Internet may give 
you some clues as to which AS's the packets are passing through.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20151223/3000423d/attachment-0001.html>


More information about the nog mailing list