<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 23/12/2015 18:04, Anurag Bhatia
wrote:<br>
</div>
<blockquote
cite="mid:CAJ0+aXa7rdEtHWkbi8_V=6P79GsRumvSgH_nvwE78aLv=FMC9w@mail.gmail.com"
type="cite">
<div>I tried querying <a moz-do-not-send="true"
href="http://ns1.btraccl.net" target="_blank">ns1.btraccl.net</a>.
(103.9.185.229) and <a moz-do-not-send="true"
href="http://ns2.btraccl.net" target="_blank">ns2.btraccl.net</a>.
(103.9.185.230) on both UDP and TCP port 53 and it's failing. </div>
<div><br>
</div>
</blockquote>
But it does work from other parts of the Internet. e.g. from the UK
(on 3 Mobile network):<br>
<br>
$ dig @103.9.185.229 btraccl.net ns<br>
<br>
; <<>> DiG 9.8.3-P1 <<>> @103.9.185.229
btraccl.net ns<br>
; (1 server found)<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
43131<br>
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2<br>
;; WARNING: recursion requested but not available<br>
<br>
;; QUESTION SECTION:<br>
;btraccl.net. IN NS<br>
<br>
;; ANSWER SECTION:<br>
btraccl.net. 86400 IN NS ns1.btraccl.net.<br>
btraccl.net. 86400 IN NS ns2.btraccl.net.<br>
<br>
;; ADDITIONAL SECTION:<br>
ns1.btraccl.net. 14400 IN A 103.9.185.229<br>
ns2.btraccl.net. 14400 IN A 103.9.185.230<br>
<br>
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.<br>
<br>
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
:-)<br>
<br>
<a class="moz-txt-link-freetext" href="http://bgp.he.net/ip/103.9.185.229">http://bgp.he.net/ip/103.9.185.229</a><br>
<br>
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 ?<br>
<br>
Furthermore, I see no entry in the APNIC database for the /22:<br>
<br>
$ whois -h whois.apnic.net 103.9.184.0/22<br>
% [whois.apnic.net]<br>
% Whois data copyright terms
<a class="moz-txt-link-freetext" href="http://www.apnic.net/db/dbcopyright.html">http://www.apnic.net/db/dbcopyright.html</a><br>
<br>
% Information related to '103.0.0.0 - 103.255.255.255'<br>
<br>
inetnum: 103.0.0.0 - 103.255.255.255<br>
netname: APNIC-AP<br>
descr: Asia Pacific Network Information Centre<br>
descr: Regional Internet Registry for the Asia-Pacific
Region<br>
descr: 6 Cordelia Street<br>
descr: PO Box 3646<br>
descr: South Brisbane, QLD 4101<br>
descr: Australia<br>
country: AU<br>
admin-c: HM20-AP<br>
tech-c: NO4-AP<br>
mnt-by: APNIC-HM<br>
mnt-lower: APNIC-HM<br>
mnt-irt: IRT-APNIC-AP<br>
status: ALLOCATED PORTABLE<br>
changed: <a class="moz-txt-link-abbreviated" href="mailto:hm-changed@apnic.net">hm-changed@apnic.net</a> 20110204<br>
source: APNIC<br>
<br>
But there *is* an entry in RADB:<br>
<br>
$ whois -h whois.radb.net 103.9.184.0/22<br>
route: 103.9.184.0/22<br>
descr: Equitel Communications Ltd.-Route Object<br>
origin: AS58616<br>
admin-c: Ahsan Habib<br>
tech-c: Rashedul Islam<br>
notify: <a class="moz-txt-link-abbreviated" href="mailto:support@equitel.com.bd">support@equitel.com.bd</a><br>
mnt-by: MAINT-AS45273<br>
changed: <a class="moz-txt-link-abbreviated" href="mailto:rashedul.islam@btraccl.com">rashedul.islam@btraccl.com</a> 20130829 #05:36:05Z<br>
source: RADB<br>
<br>
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.<br>
<br>
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.<br>
<br>
Say the remote host is x.x.x.x; then on your nameserver
103.9.185.229 run<br>
<br>
tcpdump -i eth0 -nn -s0 -v host x.x.x.x and udp port 53<br>
<br>
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).<br>
<br>
This is all just generic network debugging.<br>
<br>
Regards,<br>
<br>
Brian.<br>
<br>
</body>
</html>