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

Anurag Bhatia me at anuragbhatia.com
Thu Dec 24 01:44:10 BDT 2015


Dear Brian


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


anurag at server7:~$ ping -c 5 103.9.185.230
PING 103.9.185.230 (103.9.185.230) 56(84) bytes of data.
64 bytes from 103.9.185.230: icmp_seq=1 ttl=55 time=210 ms
64 bytes from 103.9.185.230: icmp_seq=2 ttl=55 time=209 ms
64 bytes from 103.9.185.230: icmp_seq=3 ttl=55 time=209 ms
64 bytes from 103.9.185.230: icmp_seq=4 ttl=55 time=209 ms
64 bytes from 103.9.185.230: icmp_seq=5 ttl=55 time=209 ms

--- 103.9.185.230 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 209.460/209.721/210.021/0.459 ms
anurag at server7:~$


But yes, I agree both servers should be on different subnets for avoiding
possible filtering or routing issue in one (though that isn't case here).




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

> On 23/12/2015 18:04, Anurag Bhatia wrote:
>
> I tried querying ns1.btraccl.net. (103.9.185.229) and ns2.btraccl.net.
> (103.9.185.230) on both UDP and TCP port 53 and it's failing.
>
> But it does work from other parts of the Internet. e.g. from the UK (on 3
> Mobile network):
>
> $ dig @103.9.185.229 btraccl.net ns
>
> ; <<>> DiG 9.8.3-P1 <<>> @103.9.185.229 btraccl.net ns
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43131
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;btraccl.net.                   IN      NS
>
> ;; ANSWER SECTION:
> btraccl.net.            86400   IN      NS      ns1.btraccl.net.
> btraccl.net.            86400   IN      NS      ns2.btraccl.net.
>
> ;; ADDITIONAL SECTION:
> ns1.btraccl.net.        14400   IN      A       103.9.185.229
> ns2.btraccl.net.        14400   IN      A       103.9.185.230
>
> So there is a partial/intermittent routing problem for this subnet. But
> this is why RFC 2182 says you must different nameservers on different
> backbones; then a partial loss of connectivity is not disastrous.
>
> The routing problem should of course also be looked at (although if you
> fix it, it doesn't absolve you from getting an offsite secondary :-)
>
> http://bgp.he.net/ip/103.9.185.229
>
> Interesting: there's an announcement of the whole /8, and an announcement
> of the /22, from two different ISPs. Is it possible that some providers are
> filtering out the /22 ?
>
> Furthermore, I see no entry in the APNIC database for the /22:
>
> $ whois -h whois.apnic.net 103.9.184.0/22
> % [whois.apnic.net]
> % Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html
>
> % Information related to '103.0.0.0 - 103.255.255.255'
>
> inetnum:        103.0.0.0 - 103.255.255.255
> netname:        APNIC-AP
> descr:          Asia Pacific Network Information Centre
> descr:          Regional Internet Registry for the Asia-Pacific Region
> descr:          6 Cordelia Street
> descr:          PO Box 3646
> descr:          South Brisbane, QLD 4101
> descr:          Australia
> country:        AU
> admin-c:        HM20-AP
> tech-c:         NO4-AP
> mnt-by:         APNIC-HM
> mnt-lower:      APNIC-HM
> mnt-irt:        IRT-APNIC-AP
> status:         ALLOCATED PORTABLE
> changed:        hm-changed at apnic.net 20110204
> source:         APNIC
>
> But there *is* an entry in RADB:
>
> $ whois -h whois.radb.net 103.9.184.0/22
> route:      103.9.184.0/22
> descr:      Equitel Communications Ltd.-Route Object
> origin:     AS58616
> admin-c:    Ahsan Habib
> tech-c:     Rashedul Islam
> notify:     support at equitel.com.bd
> mnt-by:     MAINT-AS45273
> changed:    rashedul.islam at btraccl.com 20130829  #05:36:05Z
> source:     RADB
>
> The thing to do is to test from those parts of the Internet where it's not
> working: traceroute to 103.9.185.229 from those places, and also traceroute
> back to those places from 103.9.185.229. If possible, ask the upstreams to
> look for the route in their BGP feeds.
>
> It could of course be that Equitel has problems with outbound routing to
> certain parts of the Internet. The way to prove this one way or another is
> with tcpdump or query logs.
>
> Say the remote host is x.x.x.x; then on your nameserver 103.9.185.229 run
>
>     tcpdump -i eth0 -nn -s0 -v host x.x.x.x and udp port 53
>
> Then on the remote host issue "dig @103.9.185.229 btraccl.net mx". Does
> the query arrive at 103.9.185.229? Does 103.9.185.229 send a reply?
> (tcpdump will answer those two questions).
>
> This is all just generic network debugging.
>
> Regards,
>
> Brian.
>
>


-- 


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/8d9f4df1/attachment.html>


More information about the nog mailing list