[bdNOG] Yahoo Mail can't communicate with my domain servers
me at anuragbhatia.com
Thu Dec 24 01:44:10 BDT 2015
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 184.108.40.206
PING 220.127.116.11 (18.104.22.168) 56(84) bytes of data.
64 bytes from 22.214.171.124: icmp_seq=1 ttl=55 time=209 ms
64 bytes from 126.96.36.199: icmp_seq=2 ttl=55 time=209 ms
64 bytes from 188.8.131.52: icmp_seq=3 ttl=55 time=209 ms
64 bytes from 184.108.40.206: icmp_seq=4 ttl=55 time=209 ms
64 bytes from 220.127.116.11: icmp_seq=5 ttl=55 time=209 ms
--- 18.104.22.168 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 22.214.171.124
PING 126.96.36.199 (188.8.131.52) 56(84) bytes of data.
64 bytes from 184.108.40.206: icmp_seq=1 ttl=55 time=210 ms
64 bytes from 220.127.116.11: icmp_seq=2 ttl=55 time=209 ms
64 bytes from 18.104.22.168: icmp_seq=3 ttl=55 time=209 ms
64 bytes from 22.214.171.124: icmp_seq=4 ttl=55 time=209 ms
64 bytes from 126.96.36.199: icmp_seq=5 ttl=55 time=209 ms
--- 188.8.131.52 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. (184.108.40.206) and ns2.btraccl.net.
> (220.127.116.11) 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 @18.104.22.168 btraccl.net ns
> ; <<>> DiG 9.8.3-P1 <<>> @22.214.171.124 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 126.96.36.199
> ns2.btraccl.net. 14400 IN A 188.8.131.52
> 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 :-)
> 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 184.108.40.206/22
> % [whois.apnic.net]
> % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
> % Information related to '220.127.116.11 - 18.104.22.168'
> inetnum: 22.214.171.124 - 126.96.36.199
> 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 188.8.131.52/22
> route: 184.108.40.206/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 220.127.116.11 from those places, and also traceroute
> back to those places from 18.104.22.168. 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 22.214.171.124 run
> tcpdump -i eth0 -nn -s0 -v host x.x.x.x and udp port 53
> Then on the remote host issue "dig @126.96.36.199 btraccl.net mx". Does
> the query arrive at 188.8.131.52? Does 184.108.40.206 send a reply?
> (tcpdump will answer those two questions).
> This is all just generic network debugging.
PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nog