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

Thu Dec 24 01:41:17 BDT 2015

On 23/12/2015 18:04, Anurag Bhatia wrote:
> I tried querying ns1.btraccl.net <http://ns1.btraccl.net>. 
> (103.9.185.229) and ns2.btraccl.net <http://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.

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