[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