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

Thu Dec 24 02:27:48 BDT 2015

Hi Brian

My replies below inline:

On Thu, Dec 24, 2015 at 1:46 AM, Brian Candler <brian at nsrc.org> wrote:

> 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: icmp_seq=1 ttl=55 time=209 ms
> 64 bytes from 103.9.185.229: icmp_seq=2 ttl=55 time=209 ms
> 64 bytes from 103.9.185.229: icmp_seq=3 ttl=55 time=209 ms
> 64 bytes from 103.9.185.229: icmp_seq=4 ttl=55 time=209 ms
> 64 bytes from 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?
>
Yes.

>
> # on server7
> dig @183.9.185.229 btraccl.net mx
> # no reply?
>
> Typo in IP here. Querying on actual IP which is 103....

anurag at server7:~$ dig @103.9.185.229 btraccl.net mx

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @103.9.185.229 btraccl.net mx
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
anurag at server7:~$

*So yes, no replies. *

> 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>
>

Your reply is bit confusing from part below since I own and manage the test
server (server7) not Jasim's server. :)

Keep in mind I am not running btraccl.net DNS servers. It's Jasim who is
having trouble. But yes I get hints you are sharing for troubleshooting. :)

For me as outsider DNS query packets are failing. I just do not see any
replies. ICMP and trace works and does ends up at right destination.

anurag at server7:~$ mtr -wrc 5 103.9.185.229
Start: Thu Dec 24 01:54:58 2015
HOST: server7.anuragbhatia.com                 Loss%   Snt   Last   Avg
 Best  Wrst StDev
  1.|-- gw.giga-dns.com                           0.0%     5    1.5   5.2
0.4  22.5   9.7
  2.|-- host-93-104-204-33.customer.m-online.net  0.0%     5   30.1   8.7
0.6  30.1  12.4
  3.|-- ae2.rt-decix-2.m-online.net               0.0%     5    7.5  11.2
7.5  21.4   5.8
  4.|-- dx1.in.airtel.com                         0.0%     5   29.0  29.4
 29.0  31.0   0.7
  5.|-- 182.79.234.201                            0.0%     5  154.5 157.0
154.3 166.1   5.1
  6.|-- aes-static-190.137.144.59.airtel.in       0.0%     5  205.1 204.9
204.0 206.7   0.9
  7.|-- 103.7.249.110                             0.0%     5  204.1 204.2
204.1 204.3   0.0
  8.|-- po1-ar1-bn1-dh.equitel.com.bd             0.0%     5  204.5 205.2
204.5 207.5   0.9
  9.|-- 103.9.186.130                            20.0%     5  212.5 211.5
210.6 212.5   0.8
 10.|-- 103.9.185.229                            20.0%     5  210.5 209.9
209.6 210.5   0.0
anurag at server7:~$

But yes if queries work for you from UK IP while failing from this German
server then surely it's issue with selective filtering. I can't relate to a
routing issue. Just some bad filtering on firewall (on server or before
server - hop 9 probably).

Thanks.

>

> 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.
>
>
>
>

-- 

Anurag Bhatia
anuragbhatia.com

PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20151224/49b25ae5/attachment.html>